Re: [systemd-devel] Request for Feedback on Design Issue with Systemd and "Consistent Network Device Naming"

2021-04-21 Thread Andrei Borzenkov
On Wed, Apr 21, 2021 at 12:20 PM Simon Foley  wrote:
...
> Here we can use the HWADDR= variable in the ifcfg-[device name] files to
> move a *specific* device name to these targeted NIC cards and ports.

Read man systemd.link.

[Match]
MACAddress= (or PermanentMACAddress=)

[Link]
Name=whatever-name-you-need
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Q: asymmetry of ExecStop and ExecStart

2021-04-14 Thread Andrei Borzenkov
On Wed, Apr 14, 2021 at 1:35 PM Ulrich Windl
 wrote:
>
> Hi!
>
> I have two services defined, one using ExecStart only, the other ExecStop 
> only.
> Then I discovered some asymmetry:
> systemd is still starting the service with the ExecStop only, while the one 
> with the ExecStart only never is stopped.
>
> Is that intended, or do I have some configuration error in the ExecStart only 
> service?
>
> The units look like this:
> # /usr/lib/systemd/system/dellcd-log-start.service
> [Unit]
> Description=Log Start on Dell LCD
> Documentation=man:dellcd(1)
> DefaultDependencies=no
> After=local-fs.target
> Before=sysinit.target
> Requires=local-fs.target
> ConditionPathExists=/usr/bin/...
>
> [Service]
> Type=oneshot
> TimeoutSec=10
> ExecStart=/usr/bin/...
>

Type=oneshot services go from "starting" directly to "dead"; they are
never active and so there is nothing to stop.

> [Install]
> WantedBy=sysinit.target
>
> # /usr/lib/systemd/system/dellcd-log-stop.service
> [Unit]
> Description=Log Stop on Dell LCD
> Documentation=man:dellcd(1)
> DefaultDependencies=no
> After=default.target
> Requires=local-fs.target
> ConditionPathExists=/usr/bin/...
>
> [Service]
> Type=oneshot
> TimeoutSec=5
> RemainAfterExit=yes
> ExecStop=/usr/bin/...
>
> [Install]
> WantedBy=default.target
>
> ---
> 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


Re: [systemd-devel] Alternatives to RequiresOverridable= ?

2021-04-10 Thread Andrei Borzenkov
On 10.04.2021 21:54, Cameron Sparr wrote:
>> Requires/Wants/RequiresOverridable= without After= is useless.
> 
> Thanks for the reply. I'm curious about this statement, do you mean it is 
> useless in general without After= or just in the context of our use-case?
> 

General. Read man systemd.unit, read this list archives - this question
pops up every month.

Requires= is useless to define startup dependencies unless you can
ensure that start job for required unit completes (successfully or not)
before start job for requiring unit is selected for processing.

> I should probably clarify the use-case too. cloud-final.service runs after 
> cloud-init.service finishes. So if ecs.service starts at the same time as 
> cloud-final.service this is acceptable. Is this the behavior that Requires= 
> alone gives us? 

I do not understand this question.

And if I understand correctly it can be overridden if the user
explicitly starts ecs.service using 'systemctl start' ?
> 

Requires= cannot be overridden.

> On 4/9/21, 11:45 PM, "systemd-devel on behalf of Andrei Borzenkov" 
>  arvidj...@gmail.com> wrote:
> 
> On 10.04.2021 03:07, Cameron Sparr wrote:
> > Hello, I work for Amazon ECS and I’ve been working on a change to one 
> of our systemd services. From what I could tell in documentation I found 
> online, it seemed that RequiresOverridable= was the perfect fit for our 
> use-case.
> > 
> >  
> > When I built a package using this field, however, I got a message 
> saying that this option is obsolete, which led me to this mailing list 
> message: 
> https://lists.freedesktop.org/archives/systemd-devel/2015-November/034880.html
> > 
> >  
> > So my question is, what would be the alternative to using 
> RequiresOverridable? What got our attention to use this flag was that user 
> input would be able to override the requirement, which is exactly what we 
> want. Does Requires= also provide that capability? From our testing it 
> _seems_ like it does but I don’t see it called out in the documentation 
> anywhere.
> > 
> >  
> > If it helps, I can describe our use-case below:
> > 
> >  
> > 1.   We have a service that executes user-defined bash scripts on 
> system startup called (simplifying) cloud-final.service.
> > 
> > 2.   We have a service called ecs.service that runs the ecs daemon 
> service. This service’s configuration file is usually made by the user 
> scripts run in cloud-final.service
> > 
> > 3.   So we wanted to make sure ecs.service starts after 
> cloud-final.service. To accomplish this we put After=cloud-final.service in 
> ecs.service.
> > 
> > 4.   But now we would also like users to be able to override 
> ecs.service waiting for cloud-final.service to finish. Because cloud-final 
> allows users to execute arbitrary bash scripts they should be able to run 
> “systemctl start ecs” and the ecs service will start.
> > 
> 
> After= dependencies are relevant only for jobs that are currently
> present in job queue. If ecs.server does not pull in cloud-final.service
> with Wants= or Requires=, you can start it explicitly without any delay.
> 
> Of course if when you request starting ecs.service the
> cloud-final.service is still being activated (its start job is active),
> then ecs.service will wait for activation to complete. There is no way
> around it I am aware of.
> 
> > 5.   So the solution we were going to do was split ecs into two 
> services:
> > 
> > a.   ecs-ready.service which has After=cloud-final.service
> > 
> > b.   ecs.service which has RequiresOverridable=ecs-ready.service
> > 
> 
> Requires/Wants/RequiresOverridable= without After= is useless. And it
> sounds like you tested Requires= without After= when you say "it seems
> to work". RequiresOverridable= with After= would still attempt to start
> required unit and wait for it. It would have ignored failure to start
> required unit, but that is not what you want.
> 
> > 6.   The idea above being that normally ecs.service would start 
> with ecs-ready (and thus after cloud-final), but if the user explicitly 
> requested it could be started without having to wait for after cloud-final.
> > 
> > 
> > 
> > ___
> > 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 mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Alternatives to RequiresOverridable= ?

2021-04-09 Thread Andrei Borzenkov
On 10.04.2021 03:07, Cameron Sparr wrote:
> Hello, I work for Amazon ECS and I’ve been working on a change to one of our 
> systemd services. From what I could tell in documentation I found online, it 
> seemed that RequiresOverridable= was the perfect fit for our use-case.
> 
>  
> When I built a package using this field, however, I got a message saying that 
> this option is obsolete, which led me to this mailing list message: 
> https://lists.freedesktop.org/archives/systemd-devel/2015-November/034880.html
> 
>  
> So my question is, what would be the alternative to using 
> RequiresOverridable? What got our attention to use this flag was that user 
> input would be able to override the requirement, which is exactly what we 
> want. Does Requires= also provide that capability? From our testing it 
> _seems_ like it does but I don’t see it called out in the documentation 
> anywhere.
> 
>  
> If it helps, I can describe our use-case below:
> 
>  
> 1.   We have a service that executes user-defined bash scripts on system 
> startup called (simplifying) cloud-final.service.
> 
> 2.   We have a service called ecs.service that runs the ecs daemon 
> service. This service’s configuration file is usually made by the user 
> scripts run in cloud-final.service
> 
> 3.   So we wanted to make sure ecs.service starts after 
> cloud-final.service. To accomplish this we put After=cloud-final.service in 
> ecs.service.
> 
> 4.   But now we would also like users to be able to override ecs.service 
> waiting for cloud-final.service to finish. Because cloud-final allows users 
> to execute arbitrary bash scripts they should be able to run “systemctl start 
> ecs” and the ecs service will start.
> 

After= dependencies are relevant only for jobs that are currently
present in job queue. If ecs.server does not pull in cloud-final.service
with Wants= or Requires=, you can start it explicitly without any delay.

Of course if when you request starting ecs.service the
cloud-final.service is still being activated (its start job is active),
then ecs.service will wait for activation to complete. There is no way
around it I am aware of.

> 5.   So the solution we were going to do was split ecs into two services:
> 
> a.   ecs-ready.service which has After=cloud-final.service
> 
> b.   ecs.service which has RequiresOverridable=ecs-ready.service
> 

Requires/Wants/RequiresOverridable= without After= is useless. And it
sounds like you tested Requires= without After= when you say "it seems
to work". RequiresOverridable= with After= would still attempt to start
required unit and wait for it. It would have ignored failure to start
required unit, but that is not what you want.

> 6.   The idea above being that normally ecs.service would start with 
> ecs-ready (and thus after cloud-final), but if the user explicitly requested 
> it could be started without having to wait for after cloud-final.
> 
> 
> 
> ___
> 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] Ordering of oneshot services and path units?

2021-03-27 Thread Andrei Borzenkov
On 27.03.2021 10:11, John Ioannidis wrote:
...
> 
> *workdir.path *
> 
> [Unit]
> Description=Trigger workdir.service when a job starts, creating a directory
> in /opt/circleci/workdir
> After=ccistated.service
> ConditionPathExists=/run/metadata/tags/resource_class
> [Path]
> PathChanged=/opt/circleci/workdir
> [Install]
> WantedBy=multi-user.target
> 
> 
...
> 
> Huh?!?!?! It's supposed to run after ccistated, and of course after mktags
> (highlighted in cyan above). It appears to be running anyway, and of course
> mktags has not gotten a chance to finish, and the ConditionExists file has
> not been created yet.
> 
> Do .path units not obey the same startup rules?
> 

By default all path units have Before=paths.target dependency which puts
them before basic.target and all service units have default dependency
After=basic.target. So you have dependency loop which systemd needs to
break; results are unpredictable.

You will need DefaultDependencies=false in your path unit (and likely
usual Conflicts=shutdown.target in addition to make sure unit is stopped
on shutdown).
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


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

2021-03-13 Thread Andrei Borzenkov
On 14.03.2021 09:03, John Ioannidis wrote:
> I have the following service file:
> 
> [Unit]
> Description=D
> After=network.target
> 
> [Service]
> ExecStart=/usr/local/sbin/mktags.py
> Type=oneshot
> User=root
> 

This is default anyway

> [Install]
> WantedBy=multi-user.target
> 
> 
> Occasionally, when the machine reboots, it does not run. Here is the
> evidence:
> 
> # uptime
> 05:50:11 up 20 min,  1 user,  load average: 0.14, 0.03, 0.01
> 
> The machine has been up for 20 minutes, so it rebooted at 05:30
> 
> # systemctl status mktags.service
> * mktags.service - D
> Loaded: loaded (/etc/systemd/system/mktags.service; enabled; vendor
> preset: enabled)
> Active: inactive (dead)
> 
> Weird... no indication of what the last process was... let's check
> journalctl:
> 
> # journalctl -u mktags.service | tail -4
> -- Reboot --
> Mar 14 05:25:22 sll9 systemd[1]: Starting D...
> Mar 14 05:25:22 sll9 systemd[1]: mktags.service: Succeeded.
> Mar 14 05:25:22 sll9 systemd[1]: Finished D.
> 
> The last time the service ran was five minutes *before* I rebooted. Other
> times the service runs fine. On the same machine, a bit later:
> 
> # uptime
> 05:57:31 up 2 min,  1 user,  load average: 0.31, 0.33, 0.14
> 
> 
> # systemctl status mktags.service
> * mktags.service - D
> Loaded: loaded (/etc/systemd/system/mktags.service; enabled; vendor
> preset: enabled)
> Active: inactive (dead) since Sun 2021-03-14 05:55:14 UTC; 2min 24s ago
>Process: 468 ExecStart=/usr/local/sbin/mktags.py (code=exited,
> status=0/SUCCESS)
>   Main PID: 468 (code=exited, status=0/SUCCESS)
> (more output indicated that the process indeed ran).
> 

When network.target became active in each case?

> 
> 
> How do I even debug something like this? I have added code in mktags.py to
> print stuff to stderr, so that journalctl picks it up. When the service
> runs, the expected output is there. Where it does not run, it is not there
> of course.
> 
> I cannot detect any other errors elsewhere; if the service fails to start,
> and I reboot, it invariably runs then. Obviously this is not a solution;
> these are unattended machines running on GCE!
> 
> 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 

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


Re: [systemd-devel] Antw: [EXT] Re: Q; syslog.socket dependency

2021-03-12 Thread Andrei Borzenkov
On Fri, Mar 12, 2021 at 10:34 AM Ulrich Windl
 wrote:
>
> >>> Reindl Harald  schrieb am 11.03.2021 um 16:23 in
> Nachricht <4422087b-9966-e7fb-66ad-4157d83f2...@thelounge.net>:
>
> >
> > Am 11.03.21 um 12:17 schrieb Ulrich Windl:
> >> Hi!
> >>
> >> I have a unit that uses logger, and I want to run it after syslog is
> > available. So I added syslog.socket as dependency, but it fails:
> >> Mar 11 12:11:02 jeos1 systemd[1]: syslog.socket: Socket service
> > syslog.service not loaded, refusing.
> >> Mar 11 12:11:02 jeos1 systemd[1]: Failed to listen on Syslog Socket.
> >>
> >> Doesn't journald also "provide" syslog.socket?
> >>
> >> Manual says:
> >> syslog.socket
> >> The socket unit syslog implementations should listen on. All
> >> userspace log messages will be made available on this socket.
> > For
> >> more information about syslog integration, please consult the
> >> Syslog Interface[2] document
> >
> > you need no dependencies for logging ‑ journald is responsible for that
> > and even available in the initrd
>
> So journald is not listening to the syslog socket? So how are messages sent to
> the journal in a compatible way?

https://www.freedesktop.org/wiki/Software/systemd/syslog/

> At least the manual page for syslog.socket is confusing then.
>
> Regards,
> Ulrich
>
> >
> > it's where early‑boot stuff comes from
> > ___
> > systemd‑devel mailing list
> > systemd‑de...@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 mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Antw: [EXT] Re: Q: Debugging missing requirements

2021-02-12 Thread Andrei Borzenkov
12.02.2021 10:04, Ulrich Windl пишет:
>>>> Andrei Borzenkov  schrieb am 11.02.2021 um 15:20 in
> Nachricht
> :
>> On Thu, Feb 11, 2021 at 1:47 PM Ulrich Windl
>>  wrote:
>>>
>>> Hi!
>>>
>>> Suspecting systemd added some requirement that isn't fulfilled after boot, 
>> preventing my units from starting I wonder:
>>> How can I debug systemd's requirements checking for units that are enabled, 
>> but not started at boot (status "inactive (dead)"?
>>
>> Usual advice is - enable debug logging.
> 
> Can I enable this for a specific unit, or just globally?
> 

Not that I am aware of. It is all or nothing.

>>
>>> Or another way: Can I list the dependencies that systemd added 
>> automatically?
>>>
>>
>> If you mean implicit or default dependencies - no. They are listed in
>> man pages, although there is no guarantee that list is complete. Your
>> best bet is source code.
> 
> 
> 
> 

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


Re: [systemd-devel] Q: Debugging missing requirements

2021-02-11 Thread Andrei Borzenkov
On Thu, Feb 11, 2021 at 1:47 PM Ulrich Windl
 wrote:
>
> Hi!
>
> Suspecting systemd added some requirement that isn't fulfilled after boot, 
> preventing my units from starting I wonder:
> How can I debug systemd's requirements checking for units that are enabled, 
> but not started at boot (status "inactive (dead)"?

Usual advice is - enable debug logging.

> Or another way: Can I list the dependencies that systemd added automatically?
>

If you mean implicit or default dependencies - no. They are listed in
man pages, although there is no guarantee that list is complete. Your
best bet is source code.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Antw: [EXT] Re: Still confused with socket activation

2021-02-09 Thread Andrei Borzenkov
On Tue, Feb 9, 2021 at 11:54 AM Ulrich Windl
 wrote:
>
> Thanks and "back to the mess": If I use libvirtd.service instead of
> libvirtd-tls.socket, it does *not* open the TLS socket, even though the
> configuration file contains "listen_tls=1"...

libvirtd --listen

Did you read the link I gave you on the pacemaker list?

https://bugzilla.redhat.com/show_bug.cgi?id=1750340#c0

quoting

--><--
Thus if the mgmt app / admin wants to use TCP/TLS sockets they have two choices

  - To continue the old approach (setting --listen in
/etc/sysconfig/libvirtd), then they MUST use 'systemctl mask ...' for
all the socket units listed above, before libvirtd.service is started.
--><--

Does it not work?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Antw: [EXT] Re: Still confused with socket activation

2021-02-08 Thread Andrei Borzenkov
08.02.2021 12:10, Ulrich Windl пишет:
> It seems systemd messes with that in a bad way.
> 

Streetlight effect ...

For the last time - systemd does exactly what unit definitions tell it
to do. Unit definitions belong to your application. If unit definitions
that come with application are not suitable for your purpose, it is
between you and your application.

> I suspect "Drop_ins"

As if systemd installs these dropins on its own.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] consider dropping defrag of journals on btrfs

2021-02-06 Thread Andrei Borzenkov
06.02.2021 00:33, Phillip Susi пишет:
> 
> Lennart Poettering writes:
> 
>> journalctl gives you one long continues log stream, joining everything
>> available, archived or not into one big interleaved stream.
> 
> If you ask for everything, yes... but if you run journalctl -b then
> shuoldn't it only read back until it finds the start of the current
> boot?


Ever tried "systemctl status" on HDD with large amount of archived
journal data? It can easily take minutes ...
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Still confused with socket activation

2021-02-06 Thread Andrei Borzenkov
04.02.2021 17:53, Simon McVittie пишет:
> On Thu, 04 Feb 2021 at 13:07:33 +0100, Reindl Harald wrote:
>> "Requires=a.service" combined with "Before=a.service" is contradictory -
>> don't you get that?
> 
> It means what it says: whenever my service is enabled, a.service must
> also be enabled, but my service has to start first (and stop last).
> 

Nitpicking - you probably mean "activated", not "enabled". "enabled"
means something entirely different in systemd (at least above config
directives are not related to "enabling" unit).

> For instance, imagine this scenario:
> 
> * my service sets something up that will trigger an action later:
>   perhaps it creates a configuration fragment in a.conf.d
> 
> * any number of other services might be doing the same as my service
> 
> * whenever at least one service has done that, when they have all finished
>   doing their setup, we need to start a.service, which will take those
>   triggers (e.g. contents of a.conf.d) and "commit" whatever is needed
>   for all of them
> 
> * if multiple services have set up a triggered action, we only want to
>   run a.service once, and it will act on all the triggers as a batch
> 

This is racy. If one of other services is activated when a.service is
already being activated due to other service, it is unpredictable
whether a.service will pick changes made by all other services. The only
way to ensure that all other services are being activated together with
(and finished before) a.service is to have a.service
Wants(Requires)/After them (or WantedBy(RequiredBy)=a.service in all of
them).

> Then my service should have Requires=a.service (because if a.service
> never runs, the "commit" action will never happen and my service will
> not do what I wanted); and it should have Before=a.service (because the
> triggers need to be in place before a.service processes them).
> 

If you never activate a.service explicitly you also never know whether
it completed successfully or not. You only have status of "some other
service" and it will fail only if a.service definition is missing; it
won't tell you anything about result of a.service itself.

While this is interesting exercise, it is really stretching systemd
dependency systems way beyond what it was deigned for.

> dpkg and RPM triggers are not (currently!) systemd services, but they
> work a lot like this. They're typically used to regenerate caches.
> 
> Another reason to combine Requires with Before is that Before is really
> a short name for "start before and stop after", and After is really a
> short name for "start after and stop before". If you're dealing with
> actions taken during system shutdown or session logout, the stop action
> might be the one that does the real work, making it more likely that
> Before dependencies are the important ones.
> 
> smcv
> ___
> 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: [EXT] Re: Still confused with socket activation

2021-02-06 Thread Andrei Borzenkov
04.02.2021 10:47, Ulrich Windl пишет:
>>>> Andrei Borzenkov  schrieb am 03.02.2021 um 19:13 in
> Nachricht :
>> 02.02.2021 12:43, Ulrich Windl пишет:
>>> Hi!
>>>
>>> Having:
>>> ---
>>> # /usr/lib/systemd/system/virtlockd.service
>>> [Unit]
>>> Description=Virtual machine lock manager
>>> Requires=virtlockd.socket
>>> Requires=virtlockd-admin.socket
>>
>> That's always wrong with After for the same units unless you can prove
>> that both socket units are always ordered Before service unit due to
>> dependency chain, at least if intention is to ensure socket units are
>> active *before* service unit. In real life nobody notices it because
>> both sockets are started much earlier which papers over race condition.
>>
>> And if after 10 years of software existence everyone still gets it wrong
>> I strongly suspect something is not right with software, not with everyone.
>>
>>> Before=libvirtd.service
>>> ...
>>> ---
>>>
>>> How would I start both sockets successfully unter program control?
>>
>> I do not understand what you want to say here, sorry. What "program
>> control" means? What exactly are you trying to do?
> 
> "program control" means "start"/"stop" vs. automatic control via
> "enable"/"disable".
> 
>>
>>> If I start one socket, I cannot start the other without an error (as 
>> libvirtd.service is running already, see my earlier message from last
> week).
>>
>> I do not see how starting socket unit is related to starting service
>> unit. Unless there was incoming traffic on socket. Also I do not
>> understand why you need to start socket units if you *already* started
>> service unit. Again, you do not really provide much coherent information
>> to do any suggestion.
> 
> I had provided the full units yesterday. Basically I don't know what to do: I
> just want to start the service and its sockets at a specific point in time and
> also want to stop those at another time.
> 

We are going in circles. socket unit is optimization that allows you to
start service unit on demand instead of starting it unconditionally. If
you want to start service unit in controlled way (and not when someone
decides to connect to socket) you should not use socket unit. Period.

>>
>> And I do not really understand the reason to use two different socket
>> units that apparently are always started together and activate the same
>> service. Just create single socket unit that listens on both sockets.
> 
> It seems the service has a config file that specified which sockets to use,

Do you mean "config file used by your application" or what?

> and some magic has to activate/deactivate the corresponding socket units.
> (BTW: You can find a corresponding question at serverfault since yesterday)
> 

You probably mean "service unit definition" when you say "config file"
then. In this case I still do not understand how it is relevant. You do
not want to enable units so it is irrelevant what those unit definitions
have in [Install] section.

>>
>>> If I mask the socket units, I cannot start the libvirtd.service.
>>> So would I disable the socket units and start libvirtd.service?
>>
>> You misunderstand what "disable" means in systemd (see remark above).
>> You cannot disable (in common sense) starting of socket units together
>> with virtlockd.service because starting of virtlockd.service will always
>> attempt to start both socket units (that is exactly what Requires/Wants
>> are about).
> 
> That would be OK, but I don't want that the socket units get activated by some
> otherm echanism I still haven't identified.
> 

If you mean to say "you observed that socket unit was activated even
though it was disabled and no corresponding service unit was being
activated" - you did not show any evidence of it so far.

If this is generic request - there is no way to prevent it in systemd.
At most you can set RefuseManualStart, but any other unit can always add
Requires/Wants=your-socket-unit.socket and your-socket-unit.socket will
be activated together with this other unit.

>>
>> Actually if they are "enabled" (in systemd sense) then they are started
>> very early during boot, long before service unit. What exact problem you
>> have in this case?
> 
> Pacemaker cluster provides a shared filesystem, so the units should not be
> started before that filesystem is mounted.

So what's wrong with starting them before pacemaker? virtlockd even
supports restarting without losin

Re: [systemd-devel] Still confused with socket activation

2021-02-04 Thread Andrei Borzenkov
03.02.2021 22:25, Benjamin Berg пишет:
> On Wed, 2021-02-03 at 20:47 +0300, Andrei Borzenkov wrote:
>> 03.02.2021 00:25, Benjamin Berg пишет:
>>> On Tue, 2021-02-02 at 22:50 +0300, Andrei Borzenkov wrote:
>>>> 02.02.2021 17:59, Lennart Poettering пишет:
>>>>>
>>>>> Note that Requires= in almost all cases should be combined with
>>>>> an
>>>>> order dep of After= onto the same unit.
>>>>
>>>> Years ago I asked for example when Requires makes sense without
>>>> After.
>>>> Care to show it? I assume you must have use case if you say "in
>>>> almost all".
>>>
>>> In the GNOME systemd units there are a few places where a Requires=
>>> is
>>> combined with Before=.
>>>
>>
>> This is functionally completely equivalent to simply using
>> Wants+Before.
>> At least as long as you rely on *documented* functions.
> 
> Requires= actually has the difference that the unit must become part of
> the transaction (if it is not active already). So you get a hard
> failure and appropriate logging if the unit cannot be added to the
> transaction for some reason.
> 

Oh, I said "documented" :) systemd documentation does not even define
what "transaction" is. You really need to know low level implementation
details to use it in this way.

But thank you, I missed this subtlety. Of course another reason could be
stop behavior.

>> Care to show more complete example and explain why Wants does not
>> work in this case?
> 
> Wants= would work fine. I think it boils down to whether you find the
> extra assertions useful. The Requires= documentation actually suggests
> using Wants= exactly to avoid this.
> 
> Benjamin
> 




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] Still confused with socket activation

2021-02-03 Thread Andrei Borzenkov
03.02.2021 21:13, Andrei Borzenkov пишет:
> 02.02.2021 12:43, Ulrich Windl пишет:
>> Hi!
>>
>> Having:
>> ---
>> # /usr/lib/systemd/system/virtlockd.service
>> [Unit]
>> Description=Virtual machine lock manager
>> Requires=virtlockd.socket
>> Requires=virtlockd-admin.socket
> 
> That's always wrong with After for the same units 
s/with/without/

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


Re: [systemd-devel] Still confused with socket activation

2021-02-03 Thread Andrei Borzenkov
02.02.2021 12:43, Ulrich Windl пишет:
> Hi!
> 
> Having:
> ---
> # /usr/lib/systemd/system/virtlockd.service
> [Unit]
> Description=Virtual machine lock manager
> Requires=virtlockd.socket
> Requires=virtlockd-admin.socket

That's always wrong with After for the same units unless you can prove
that both socket units are always ordered Before service unit due to
dependency chain, at least if intention is to ensure socket units are
active *before* service unit. In real life nobody notices it because
both sockets are started much earlier which papers over race condition.

And if after 10 years of software existence everyone still gets it wrong
I strongly suspect something is not right with software, not with everyone.

> Before=libvirtd.service
> ...
> ---
> 
> How would I start both sockets successfully unter program control?

I do not understand what you want to say here, sorry. What "program
control" means? What exactly are you trying to do?

> If I start one socket, I cannot start the other without an error (as 
> libvirtd.service is running already, see my earlier message from last week).

I do not see how starting socket unit is related to starting service
unit. Unless there was incoming traffic on socket. Also I do not
understand why you need to start socket units if you *already* started
service unit. Again, you do not really provide much coherent information
to do any suggestion.

And I do not really understand the reason to use two different socket
units that apparently are always started together and activate the same
service. Just create single socket unit that listens on both sockets.

> If I mask the socket units, I cannot start the libvirtd.service.
> So would I disable the socket units and start libvirtd.service?

You misunderstand what "disable" means in systemd (see remark above).
You cannot disable (in common sense) starting of socket units together
with virtlockd.service because starting of virtlockd.service will always
attempt to start both socket units (that is exactly what Requires/Wants
are about).

Actually if they are "enabled" (in systemd sense) then they are started
very early during boot, long before service unit. What exact problem you
have in this case?

> Unfortunately if someone (update when vendor-preset is enabled) re-enables 
> the socket units, it would break things, so I tried to mask them, but that 
> failed, too.
> error: Could not issue start for prm_virtlockd: Unit virtlockd.socket is 
> masked.
> 
> 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


Re: [systemd-devel] Still confused with socket activation

2021-02-03 Thread Andrei Borzenkov
03.02.2021 00:25, Benjamin Berg пишет:
> On Tue, 2021-02-02 at 22:50 +0300, Andrei Borzenkov wrote:
>> 02.02.2021 17:59, Lennart Poettering пишет:
>>>
>>> Note that Requires= in almost all cases should be combined with an
>>> order dep of After= onto the same unit.
>>
>> Years ago I asked for example when Requires makes sense without
>> After.
>> Care to show it? I assume you must have use case if you say "in
>> almost all".
> 
> In the GNOME systemd units there are a few places where a Requires= is
> combined with Before=.
> 

This is functionally completely equivalent to simply using Wants+Before.
At least as long as you rely on *documented* functions.

Care to show more complete example and explain why Wants does not work
in this case?



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] Still confused with socket activation

2021-02-02 Thread Andrei Borzenkov
02.02.2021 17:59, Lennart Poettering пишет:
> 
> Note that Requires= in almost all cases should be combined with an
> order dep of After= onto the same unit.

Years ago I asked for example when Requires makes sense without After.
Care to show it? I assume you must have use case if you say "in almost all".
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] successful mount starts a service - how?

2021-01-18 Thread Andrei Borzenkov
19.01.2021 04:00, lejeczek пишет:
> hi guys.
> 
> I'm fiddling with it but have run out of options/ideas.
> What I would like to have is systemd starts a service when a device, in
> my case a crypt-luks device, gets mounted which mount would happen by
> manual 'cryptsetup open'

I am not aware that "cryptsetup open" mounts anything. I do not even see
any option to specify mount point in its invocation. Please show exact
command you are using that "mounts" encrypted container.

> I see when that manual action takes place then systemd changes status of
> a home.mount (which is in fstab) to "active" - and it's here where I
> hope systemd would auto-start a service.
> Is such a "simple" thing possible?
> many thanks, L
> ___
> 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] emergency shutdown, don't wait for timeouts

2020-12-27 Thread Andrei Borzenkov
27.12.2020 17:00, Reindl Harald пишет:
> 
> 
> Am 27.12.20 um 14:43 schrieb Andrei Borzenkov:
>> 27.12.2020 16:26, Germano Massullo пишет:
>>> Good day, I recently joined apcupsd (APC UPS Power Control Daemon)
>>> package maintainers on Fedora/CentOS/RHEL.
>>> After a power failure, apcupsd shuts down the system with a command
>>> almost identical to
>>> shutdown -h -H now
>>> Usually when you normally shutdown your system, you may notice certain
>>> services taking too much time to terminate and triggering a timeout
>>> value before systemd forces them to terminate. I would like to ask if
>>> there is a way to force the system to shutdown without waiting for these
>>> timeouts in case an emergency like a power failure.
>>>
>>
>> You can force shutdown without going via normal stop of services.
>>
>> systemctl --force poweroff
> 
> but that is only a part of the solution because normally most services
> don't take long to stop and they should be normally stopped whenever
> possible
> 
> the real solution would a option to reduce the timeouts
> 
> systemctl --timeout=5 poweroff

sytemctl does not have this option.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] emergency shutdown, don't wait for timeouts

2020-12-27 Thread Andrei Borzenkov
27.12.2020 16:26, Germano Massullo пишет:
> Good day, I recently joined apcupsd (APC UPS Power Control Daemon)
> package maintainers on Fedora/CentOS/RHEL.
> After a power failure, apcupsd shuts down the system with a command
> almost identical to
> shutdown -h -H now
> Usually when you normally shutdown your system, you may notice certain
> services taking too much time to terminate and triggering a timeout
> value before systemd forces them to terminate. I would like to ask if
> there is a way to force the system to shutdown without waiting for these
> timeouts in case an emergency like a power failure.
> 

You can force shutdown without going via normal stop of services.

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


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

2020-12-24 Thread Andrei Borzenkov
On Thu, Dec 24, 2020 at 5:48 AM John  wrote:
>
> I need to have the following start
> /usr/lib/systemd/user/pulseaudio.service so it can make use of
> pulseaudio.  Using a After= or Wants= does not work.  What is the
> correct way to have a system service like this run a user service
> unit?
>

No, that's not possible. PA also supports system service, if this is a
kiosk system, maybe you can use it instead.

> % cat /usr/lib/systemd/system/kodi.service
> [Unit]
> Description=Kodi standalone (GBM)
> After=remote-fs.target network-online.target nss-lookup.target
> sound.target bluetooth.target polkit.service upower.service
> mysqld.service
> Wants=network-online.target polkit.service upower.service
> Conflicts=getty@tty1.service
>
> [Service]
> User=kodi
> Group=kodi
> EnvironmentFile=-/etc/conf.d/kodi-standalone
> TTYPath=/dev/tty1
> Environment=WINDOWING=gbm
> ExecStart=/usr/bin/kodi-standalone
> ExecStop=/usr/bin/killall --user kodi --exact --wait kodi-gbm
> Restart=on-abort
> StandardInput=tty
> StandardOutput=journal
>
> [Install]
> Alias=display-manager.service
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] default.target and external symlinks

2020-12-23 Thread Andrei Borzenkov
23.12.2020 18:28, Alexander Sbitnev пишет:
>   Hi there!
>   I am trying to use upcoming Debian 11 Bullseye with read-only root
> filesystem.
> And I discovered SystemD behaviour change compared to Debian 9. It is not
> related to read-only root by itself and can be easily reproduced with a
> normal installation.
> With new Debian 11 SystemD (247.1-3) it is not possible to use chain of
> symlinks from /etc/systemd/system/default.target to choose target if chain
> include elements outside of SystemD directories (/etc/systemd/system/ or
> /lib/systemd/system/).
> For example next chain work fine:
> /etc/systemd/system/default.target -> default.redirect.target ->
> /lib/systemd/system/default.test.target ->
> /lib/systemd/system/multi-user.target
> 
> And if I move default.redirect.target from /etc/systemd/system/ to /etc/
> system will not boot correctly. Problematic chain looks next way:
> /etc/systemd/system/default.target -> /etc/default.redirect.target ->
> /lib/systemd/system/multi-user.target
> 
> Chain by itself looks valid:
> root@deb11tiny:/etc/systemd/system# cat /etc/systemd/system/default.target
> #  SPDX-License-Identifier: LGPL-2.1-or-later
> #
> #  This file is part of systemd.
> #
> #  systemd is free software; you can redistribute it and/or modify it
> #  under the terms of the GNU Lesser General Public License as published by
> #  the Free Software Foundation; either version 2.1 of the License, or
> #  (at your option) any later version.
> 
> [Unit]
> Description=Multi-User System
> Documentation=man:systemd.special(7)
> Requires=basic.target
> Conflicts=rescue.service rescue.target
> After=basic.target rescue.service rescue.target
> AllowIsolate=yes
> 
> root@deb11tiny:/etc/systemd/system# systemctl get-default
> multi-user.target
> 
> And system actually booting. And SystemD seems to know which target it
> should boot as I can see in output next lines:
> ...
> [4.508581] systemd[1]: Queued start job for default target Multi-User
> System.
> ...
> [  OK  ] Reached target Multi-User System.
> 
> But the booted system will get most of its units inactive. Network, sshd...
> even gettys stays unstarted.
> Is it a problem with Debian SystemD build? Or is it correct behaviour?
> 

The fact that systemd does not alias default.target to multi-user.target
is likely intentional, judging by comment in
src/shared/unit-file.c:unit_file_build_name_map()

/* Check if the symlink goes outside of
our search path.
 * If yes, it's a linked unit file or
mask, and we don't care about the target name.
 * Let's just store the link destination
directly.
 * If not, let's verify that it's a good
symlink. */

So systemd loads *content* of default.target which is valid unit
definition and proceeds, but because default.target is not associated
with  multi-user.target it does not pull in all multi-user.tagret
dependencies.

In this case systemctl get-default returning multi-user.target is a bug.
It must follow the the same rules and use the same unit cache (at least,
it must behave as if it is using the same unit cache). Currently it
chases symlinks which was also historical systemd behavior. This
probably explains why it works for you in the past.


> If this behaviour is unexpected I can supply any additional info but I
> don't know there to put it. Should I open a new bug in Debian tracker and
> put it there or can I just share it from cloud storage and supply a link to
> this list?
> 

Open issue on systemd tracker.

> Another interesting note to add: manually adding
> "systemd.unit=multi-user.target" to boot params allows the system to boot
> normal. So it definitely looks like a bug to me.
> 


Yes, because in this case systemd also starts all dependencies on
multi-user.tagret (i.e. most of "enabled" units).
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Services with multiple pre-requisites

2020-12-21 Thread Andrei Borzenkov
21.12.2020 20:23, freedesk...@priatel.co.uk пишет:
> Perhaps I'm missing something, but that's still not doing what I expect.
> 
> Here's what I have...
> 
> #- /etc/systemd/system/first.target -#
> [Unit]
> Description=Started first
> Wants=third.service
> 
> #- /etc/systemd/system/second.target -#
> [Unit]
> Description=Started second
> Wants=third.service
> 
> #- /etc/systemd/system/third.service -#
> [Unit]
> Description=Third service
> Requisite=first.target second.target
> 
> [Service]
> Type=simple
> ExecStartPre=/usr/bin/logger -t "FooBar" -p daemon.notice "%P is starting"
> ExecStart=/tmp/third.sh
> Restart=always
> ExecStop=/usr/bin/logger -t "FooBar" -p daemon.notice "%P has stopped"
> 
> 
> #- /tmp/third.sh -#
> #!/bin/bash
> count=1
> while (( count > 0 ))
> do
>   /usr/bin/logger -i -t "FooBar" -p daemon.notice "Counter: $count"
>   (( count++ ))
>   sleep 5
> done
> 
> And here's what I observe happening. When I start *either* first.target or
> second.target, the third.service is started. That's not what I expect or
> want though. The third.service should be requisite on **both** first.target
> and second.target.
> 
> localhost# systemctl start first.target
> 
> 2020-12-21T17:03:51.039814+00:00 localhost systemd[1]: Starting Third
> service...
> 2020-12-21T17:03:51.041827+00:00 localhost FooBar: Third service is starting
> 2020-12-21T17:03:51.042451+00:00 localhost systemd[1]: Started third
> service.
> 2020-12-21T17:03:51.045033+00:00 localhost systemd[1]: Reached target
> Started first.
> 2020-12-21T17:03:51.045114+00:00 localhost systemd[1]: Started second is not
> active.
> 2020-12-21T17:03:51.045843+00:00 localhost FooBar[29048]: Counter: 1
> 2020-12-21T17:03:56.048463+00:00 localhost FooBar[644]: Counter: 2
> 2020-12-21T17:04:01.050951+00:00 localhost FooBar[4881]: Counter: 3
> 
> localhost# systemctl stop first.target
> ...
> localhost# systemctl start second.target
> 
> 2020-12-21T17:04:47.544840+00:00 localhost systemd[1]: Starting Third
> service...
> 2020-12-21T17:04:47.546885+00:00 localhost FooBar: Third Service is starting
> 2020-12-21T17:04:47.555459+00:00 localhost systemd[1]: Started third
> service.
> 2020-12-21T17:04:47.56+00:00 localhost FooBar[3938]: Counter: 1
> 2020-12-21T17:04:47.555666+00:00 localhost systemd[1]: Started first is not
> active.
> 2020-12-21T17:04:47.555730+00:00 localhost systemd[1]: Reached target
> Started second.
> 2020-12-21T17:04:52.553867+00:00 localhost FooBar[8255]: Counter: 2
> 2020-12-21T17:04:57.554741+00:00 localhost FooBar[12157]: Counter: 3
> 
> localhost# systemctl stop second.target
> 
> Note particularly the `systemd` logs:
> 
> 2020-12-21T17:03:51.045114+00:00 localhost systemd[1]: Started second is not
> active.
> 2020-12-21T17:04:47.555666+00:00 localhost systemd[1]: Started first is not
> active.
> 
> It has noticed and logged that one of the Requisite targets for the Third
> service isn't active, but it starts it anyway :-(
> 
> That seems to go directly against the documented behaviour (at
> https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Requisite
> =):
>   | Requisite=
>   | 
>   | Similar to Requires=. However, if the units listed here are not
>   | started already, they will not be started and the starting of
>   | this unit will fail immediately.
> 
> Is this a bug, or am I still missing something?
> 

You miss ordering dependencies. Neither Requires not Requisite work
without proper After/Before.

systemd manuals make impression that dependencies are between units.
This is wrong - dependencies are between jobs. If unit B has "Requisite:
A" what happens is - systemd implicitly creates job for unit A that
verifies current state of unit A and if it is not active fails pending
start job for unit B. Without proper ordering both jobs (verify state of
unit A and start unit B) run concurrently and the order is
non-deterministic (or may be it is but then it is always "wrong" for
your purpose :) ), so in your case job for Second runs too late, when
Third is already started and there is no pending job to fail.



> Martin
> 
> -Original Message-
> From: Lennart Poettering  
> Sent: 21 December 2020 15:32
> To: freedesk...@priatel.co.uk
> Cc: systemd-devel@lists.freedesktop.org
> Subject: Re: [systemd-devel] Services with multiple pre-requisites
> 
> On Mo, 21.12.20 14:43, freedesk...@priatel.co.uk (freedesk...@priatel.co.uk)
> wrote:
> 
>> Hi
>>
>> I have two "primary" services running on a Linux server with `systemd` 
>> that may be started at approximately the same time, or could just as 
>> easily be started days apart. When started, they take a few seconds to
> reach "ready"
>> state, and can signal that readiness however I choose.
>>
>> I have a third (and fourth, fifth, etc...) service which:
>>   * must not start before both Service 1 & Service 2 are ready
>>   * must start as soon as possible once both Service 1 & Service 2 are
> ready
>>   * must be 

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

2020-12-13 Thread Andrei Borzenkov
14.12.2020 05:08, John пишет:
> If I call systemctl to shutdown or reboot, the effect is that it does
> not honor kodi-x11.service's ExecStop= line which results in an
> unclean exit of kodi and of data loss since kodi writes out some data
> when it exits.  By contrast, calling systemctl to stop the service
> works as expected.
> 
> Does anyone with more knowledge that I understand the differences with
> respect to this aspect of stopping a service as it relates to:
> 
> 1) systemctl stop kodi-x11 (which behaves as expected)
> 2) systemctl reboot (which does not behave as expected)
> 
> Here is kodi-x11.service:
> 
> [Unit]
> Description=Kodi standalone (X11)
> After=remote-fs.target systemd-user-sessions.service

If your application creates user session, on shutdown systemd will stop
existing sessions and it happens independently of your service.

> network-online.target nss-lookup.target sound.target bluetooth.target
> polkit.service upower.service mysqld.service
> Wants=network-online.target polkit.service upower.service
> Conflicts=getty@tty1.service
> 
> [Service]
> User=kodi
> Group=kodi
> EnvironmentFile=-/etc/conf.d/kodi-standalone
> PAMName=login
> TTYPath=/dev/tty1
> Environment=WINDOWING=x11
> ExecStart=/usr/bin/xinit /usr/bin/kodi-standalone -- :0 -quiet -nolisten tcp 
> vt1
> ExecStop=/usr/bin/killall --user kodi --exact --wait kodi-x11
> Restart=on-abort
> StandardInput=tty
> StandardOutput=journal
> 
> [Install]
> Alias=display-manager.service
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 

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


Re: [systemd-devel] Journald retaining logs for only 10 days

2020-11-16 Thread Andrei Borzenkov
14.11.2020 22:18, Nikolaus Rath пишет:
> On Nov 14 2020, Andrei Borzenkov  wrote:
>> 14.11.2020 14:32, Nikolaus Rath пишет:
>> ...
>>>>>
>>>>> # grep -vE '^#' /etc/systemd/journald.conf
>>>>>
>>>>> [Journal]
>>>>> SystemMaxUse=300M
>>>>
>>>> The number shown by disk usage (320 MB) is higher than 300 MB. Maybe also 
>>>> check the files
>>>> in `/var/log/journal`.
>>>
>>> It's a bit bigger on disk too:
>>>
>>> # du -hs /var/log/journal
>>> 321M/var/log/journal
>>>
>>> journalctl --verify does not find any errors.
>>>
>>>
>>> Could that be related to the short retention, or is this an unrelated 
>>> problem?
>>>
>>
>> It is not a "problem". You told journald to keep 300M of data and it
>> does exactly that.
> 
> Hu? As far as I can tell, I told it to keep 300 MB and it's using 320
> MB.

For all I can tell, SystemMaxUse applies to inactive journal files only
- this sets target how many archived files to delete. systemd will
switch to new file and archive current if currently active file exceeds
max size. Max journal file size is by default set to 1/8th of max
allowed space. Which means with SystemMaxUse=300M max journal file size
is set to 37.5MiB and at any time you may have up to 300MiB of old files
and one currently active file which may grow up to 37.5MiB. So 337.5MiB
in total.

And my understanding is that every user's journal adds to this - so
basically you will have additionally 37.5MiB x number of active user
sessions.

If someone more familiar with journal internals will confirm it, it
calls for documentation update. While manual page says "Also note that
only archived files are deleted to reduce the space occupied by journal
files" it does not make clear that limits effectively apply to archived
files only and active files may additionally consume up to
SystemMaxFileSize each before something triggers rotation.

This is actually in line with SystemMaxFiles which does not remove
active files either. So setting SystemMaxFiles=0 will remove archived
files but leave any active file untouched.

> Furthermore, in these 320 MB it seemingly only stored 27 MB worth of
> log data.
> 

That's rather different issue.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Journald retaining logs for only 10 days

2020-11-14 Thread Andrei Borzenkov
14.11.2020 14:32, Nikolaus Rath пишет:
...
>>>
>>> # grep -vE '^#' /etc/systemd/journald.conf
>>>
>>> [Journal]
>>> SystemMaxUse=300M
>>
>> The number shown by disk usage (320 MB) is higher than 300 MB. Maybe also 
>> check the files
>> in `/var/log/journal`.
> 
> It's a bit bigger on disk too:
> 
> # du -hs /var/log/journal
> 321M  /var/log/journal
> 
> journalctl --verify does not find any errors.
> 
> 
> Could that be related to the short retention, or is this an unrelated problem?
> 

It is not a "problem". You told journald to keep 300M of data and it
does exactly that.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] log_target=console and multiple console devices

2020-11-14 Thread Andrei Borzenkov
Quoting https://freedesktop.org/wiki/Software/systemd/Debugging/

console= can be specified multiple times, systemd will output to all of
them.


That's wrong. systemd will write to /dev/console and according to kernel
documentation (and my experience :) ) kernel will forward it only to the
last listed console. From
https://www.kernel.org/doc/html/latest/admin-guide/serial-console.html:

You can specify multiple console= options on the kernel command line.
Output will appear on all of them. The last device will be used when you
open /dev/console.

So *kernel* output will indeed be duplicated to all of them, but not
output written to /dev/console.


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


[systemd-devel] Man page description for systemd.log_target & Co is completely lost.

2020-11-14 Thread Andrei Borzenkov
man systemd(1):

$SYSTEMD_LOG_TARGET
===
systemd reads the log target from this environment variable. This can be
overridden with --log-target=.

--log-target=
=
Set log target. See systemd.log_target above.

systemd.log_color, systemd.log_level=, systemd.log_location,
systemd.log_target=, systemd.log_time, systemd.log_tid

Controls log output, with the same effect as the $SYSTEMD_LOG_COLOR,
$SYSTEMD_LOG_LEVEL, $SYSTEMD_LOG_LOCATION, $SYSTEMD_LOG_TARGET,
$SYSTEMD_LOG_TIME, and $SYSTEMD_LOG_TID environment variables described
above. systemd.log_color, systemd.log_location, systemd.log_time, and
systemd.log_tid= can be specified without an argument, with the same
effect as a positive boolean.

Oops. Déjà Vu ...

Sepulka – pl: sepulki, a prominent element of the civilization of
Ardrites from the planet of Enteropia; see "Sepulkaria"
Sepulkaria – sing: sepulkarium, establishments used for sepuling; see
"Sepuling"
Sepuling – an activity of Ardrites from the planet of Enteropia; see
"Sepulka"


Looking in history ...

commit c035f3766c7808955a7d2e42316b3f008a236fcc
Author: Zbigniew Jędrzejewski-Szmek 
Date:   Fri Nov 15 13:30:02 2019 +0100

man: significantly downgrade the Options section in systemd(1)

This structure of the man page originates from the time when systemd was
installed on top of sysvinit systems, and users had an actual chance to
interact with the systemd binary directly. Nowadays it is almost
never called
directly, so let's properly explain this in the overview.

The Options section is moved down below the kernel command line,
those options
are only needed in special circumstances. Let's refer the reader to the
description of the kernel command line options, and not duplicate the
descriptions (which makes the text longer than necessary and
increases chances
for discrepancies).

Well, I do not see any reference to "kernel command line" in description
above. There is cross reference to kernel-command-line(7) in See also
... let's try it.


systemd.unit=, rd.systemd.unit=, systemd.dump_core,
systemd.early_core_pattern=, systemd.crash_chvt, systemd.crash_shell,
systemd.crash_reboot, systemd.confirm_spawn, systemd.service_watchdogs,
systemd.show_status, systemd.status_unit_format=, systemd.log_target=,
systemd.log_level=, systemd.log_location=, systemd.log_color,
systemd.default_standard_output=, systemd.default_standard_error=,
systemd.setenv=, systemd.machine_id=, systemd.unified_cgroup_hierarchy,
systemd.legacy_systemd_cgroup_controller
=
Parameters understood by the system and service manager to control
system behavior. For details, see systemd(1).

We are back to square one.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Query currently active journald configuration option

2020-11-10 Thread Andrei Borzenkov
09.11.2020 19:09, Lennart Poettering пишет:
> On Mo, 09.11.20 08:48, Andrei Borzenkov (arvidj...@gmail.com) wrote:
> 
>> Is it possible to query configuration options in effect in running
>> journald instance?
> 
> Besides the brief log output it does itself, no there's currently no
> way.
> 
> We never had that because journald can't use D-Bus, because D-Bus
> itself is a client to journald. However, we recently added support for
> a Varlink interface, which requires no broker daemon, and hence just
> works. It would make a ton of sense to extend that varlink IPC
> interface to expose some information about configuration, its state
> and statistics. Happy to review/merge a patch for that.
> 
>>
>> Background - when user asks question about journald, the first
>> information is current settings (like whether persistence is enabled or
>> not). It needs fetching files from multiple places which varies between
>> distributions (/lib vs /usr/lib). Not really user friendly and not
>> possible to do with simple command.
> 
> Fetching files from /lib or /usr/lib? What precisely do you mean?
> 

_CONF_PATHS_SPLIT_USR_NULSTR
_CONF_PATHS_SPLIT_USR

> For such build-time params we expose systemd.pc as pkg-config file,
> which has various paths as variables.
> 

Now explain it to user who barely knows what command line is and most
likely does not even have development environment installed.

Besides, what pkg-config variable exactly controls location of
configuration files? For all I can tell such variable does not exist.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] Query currently active journald configuration option

2020-11-08 Thread Andrei Borzenkov
Is it possible to query configuration options in effect in running
journald instance?

Background - when user asks question about journald, the first
information is current settings (like whether persistence is enabled or
not). It needs fetching files from multiple places which varies between
distributions (/lib vs /usr/lib). Not really user friendly and not
possible to do with simple command.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Which udev action is run on boot for my device?

2020-10-25 Thread Andrei Borzenkov
25.10.2020 20:36, Marcin Kocur пишет:
> Hello,
> 
> as the topic states, I want to know which action(s) from "add",
> "remove", "change", "move", "online", "offline", "bind", and "unbind"
> were triggered on my device. Is there any way to check that?
> 
> At the beginning of  /usr/lib/udev/rules.d/49-sane.rules there is:
> 
> ACTION!="add", GOTO="libsane_rules_end"
> 
> Udevadm info doesn't show libsane_matched property for my scanner.
> 
> If I trigger the device manually with action "change", the variable is
> still not there, as per the rule.
> 
> But if I trigger it with "add", the variable is there and also uaccess
> rule gets executed.
> 
> So the ultimate quesiton is: what kind of trigger was executed on my
> device on boot time?
> 

When device is detected by kernel it emits ADD event. This may happen in
initrd where not all rules are available. Later traditionally equivalent
of "udevadm trigger" was executed; in current upstream systemd sources
this invokes

ExecStart=udevadm trigger --type=subsystems --action=add
ExecStart=udevadm trigger --type=devices --action=add


Your distribution is free to not perform udevadm trigger or to modify
service to call it with different parameters. So it is something that
cannot be answered upstream.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] btrfs raid not ready but systemd tries to mount it anyway

2020-10-16 Thread Andrei Borzenkov
16.10.2020 18:51, Lennart Poettering пишет:
>>
>> Ths btrfs udev rule file appears to be missing in the initrd. The
>> block devices with the btrfs file systems on them will thus be marked
>> ready in systemd instantly instead of being delayed until all other
>> devices of the same btrfs fs have shown up in udev too.
>>
>> Fix your initrd.
> 
> So my educated guess is that this is a dracut bug: it excludes the
> btrfs udev rule file from the initrd unless the root fs is btrfs.
> 
> But this doesn't work, because the absence of that file means that all
> btrfs file systems will be marked as ready instantly as they appear,
> which then blows up later if during later boot btrfs file systems that
> are backed by multiple devices shall be mounted.
> 
> It's basically a race: if yor block devices appear in the initrd
> already, then you lost,

It is unmanageable. It means we now have to include half of kernel and
user space because god knows what could be required by udev rules. How
should dracut even supposed to know what to include?

initrd is needed to mount root. Period. If you broke it by carrying over
incomplete udev database state from initrd, it is up to *you* to fix it,
not forcing copy of root system into initrd.

> because all such devices will be instantly be
> marked "ready to be mounted" because the udev rule file is missing
> there. However, if the block devices take longer to appear, and are
> thus first seen after the initrd→host transition, then all will be
> good, as the udev rules file for it exists there, and the devices are
> not marked ready until all necessary devices have shown up in udev.
> 
> Fix is: dracut should just include the file unconditionally. It's
> tiny.
> 
> If it really really insist to not include it on systems where btrfs isn't
> used, then it should scan the host for any btrfs use at all. it's not
> sufficient to determine whether the rootfs is btrfs or not.
> 
> Anyway, please report to dracut.
> 
> 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] Crond session, pam_access and pam_systemd

2020-10-14 Thread Andrei Borzenkov
14.10.2020 15:23, Thomas HUMMEL пишет:
> 
> 
> On 14/10/2020 13:24, Andrei Borzenkov wrote:
>> On Wed, Oct 14, 2020 at 11:42 AM Thomas HUMMEL
>>  wrote:
>>>
>>> Hello,
>>>
>>> thanks for your answer. It's getting clearer.
>>>
>>> Still : why would the user crond runs on behalf of needs to be allowed
>>> in access.conf to access the systemd-user service ?
>>> My understanding is that the user@.service creation needs this
>>> service type (or just the systemd --user creation ?) such a rule in
>>> access.conf is not needed for let's say a ssh login first session ?
>>>
>>
>> Does PAM configuration for SSH include pam_systemd on your system?
> 
> Yes, via the password-auth include :
> 
> 
> sshd:
> 
> 
> session    include  password-auth
> 
> password-auth:
> 
> 
> -session    optional pam_systemd.so
> 


And both sshd and crond include pam_access in their configuration?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Crond session, pam_access and pam_systemd

2020-10-14 Thread Andrei Borzenkov
On Wed, Oct 14, 2020 at 11:42 AM Thomas HUMMEL  wrote:
>
> Hello,
>
> thanks for your answer. It's getting clearer.
>
> Still : why would the user crond runs on behalf of needs to be allowed
> in access.conf to access the systemd-user service ?
> My understanding is that the user@.service creation needs this
> service type (or just the systemd --user creation ?) such a rule in
> access.conf is not needed for let's say a ssh login first session ?
>

Does PAM configuration for SSH include pam_systemd on your system?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] btrfs raid not ready but systemd tries to mount it anyway

2020-10-11 Thread Andrei Borzenkov
11.10.2020 23:57, Chris Murphy пишет:
> Hi,
> 
> A Fedora 32 (systemd-245.8-2.fc32) user has a 10-drive Btrfs raid1 set
> to mount in /etc/fstab:
> 
> UUID=f89f0a16-  /srv   btrfs  defaults,nofail,x-systemd.requires=/  
> 0 0
> 
> For some reason, systemd is trying to mount this file system before
> all ten devices are ready. Supposedly this rule applies:
> https://github.com/systemd/systemd/blob/master/rules.d/64-btrfs.rules.in
> 
> Fedora does have /usr/lib/udev/rules.d/64-btrfs.rules but I find no
> reference at all to this rule when the user boots with 'rd.udev.debug
> systemd.log_level=debug'. The entire journal is here:
> 
> https://drive.google.com/file/d/1jVHjAQ8CY9vABtM2giPTB6XeZCclm7R-/view
> 

Educated guess - rule is missing in initrd and you do not run udev
trigger after switch to root.


> I expect a workaround would be to use mount option:
> 
> x-systemd.automount,noauto,nofail,x-systemd.requires=/
> 
> In fact, I'm not sure x-systemd.requires is needed because / must be
> mounted successfully to read /etc/fstab in the first place; in order
> to know to mount this file system at /srv
> 

That makes no sense. You cannot boot without root being present, it is
controlled outside of normal boot sequence.

> Anyway I'm mainly confused why the btrfs udev rule is seemingly not
> applied in this case.
> 

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


Re: [systemd-devel] systemd doesn't see ttyPS0 devices from udev

2020-09-22 Thread Andrei Borzenkov
On Tue, Sep 22, 2020 at 2:53 PM Mantas Mikulėnas  wrote:
>
> On Tue, Sep 22, 2020 at 1:46 PM Andrei Borzenkov  wrote:
>>
>> On Tue, Sep 22, 2020 at 1:35 PM ZhouPeng  wrote:
>> >
>> > Hi all,
>> >
>> > When I use Fedora image as rootfs on Xilinx PYNQ-Z2, I encountered the 
>> > issue  when use the /dev/ttyPS0.
>> > I think the issue is because systemd and udev on fedora can didn't detect 
>> > ttyPS0 properly. Do I need to install any other package or do some special 
>> > configuration?
>> >
>> > **systemd version the issue has been seen with**
>> > udevadm --version
>> > 237
>> > systemd-udev.riscv64 237-1.0.riscv64.fc28
>> >
>> >
>> > **Unexpected behaviour you saw**
>> > We can see ttyPS0 boots ok in the kernel boot period:
>> > [0.18] console [ttyPS0] enabledat MMIO 0xe000 (irq = 2, 
>> > base_baud = 625) is a xuartps
>> > [0.18] console [ttyPS0] enabled
>> >
>> > But, when boot into systemd, it failed on dev ttyPS0:
>> > [ TIME ] Timed out waiting for device dev-ttyPS0.device. // **here**
>>
>> systemd only monitors for devices with "sysemd" tag. Tags are assigned
>> by udev rules. You should add rule to assign tag to ttyPS0. I have no
>> idea what it is, but something like
>>
>> ACTION!="remove", KERNEL=="ttyPS0", TAG+="systemd"
>>
>> should do it. Whether this should go upstream depends on how common
>> this device is.
>
>
> Well yes, but that should have been already covered by the existing upstream 
> rules:
>
> 99-systemd.rules:12:SUBSYSTEM=="tty", 
> KERNEL=="tty[a-zA-Z]*|hvc*|xvc*|hvsi*|ttysclp*|sclp_line*|3270/tty[0-9]*", 
> TAG+="systemd"
>

Are you sure ttyPS0 has the "tty" subsystem?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd doesn't see ttyPS0 devices from udev

2020-09-22 Thread Andrei Borzenkov
On Tue, Sep 22, 2020 at 1:35 PM ZhouPeng  wrote:
>
> Hi all,
>
> When I use Fedora image as rootfs on Xilinx PYNQ-Z2, I encountered the issue  
> when use the /dev/ttyPS0.
> I think the issue is because systemd and udev on fedora can didn't detect 
> ttyPS0 properly. Do I need to install any other package or do some special 
> configuration?
>
> **systemd version the issue has been seen with**
> udevadm --version
> 237
> systemd-udev.riscv64 237-1.0.riscv64.fc28
>
>
> **Unexpected behaviour you saw**
> We can see ttyPS0 boots ok in the kernel boot period:
> [0.18] console [ttyPS0] enabledat MMIO 0xe000 (irq = 2, base_baud 
> = 625) is a xuartps
> [0.18] console [ttyPS0] enabled
>
> But, when boot into systemd, it failed on dev ttyPS0:
> [ TIME ] Timed out waiting for device dev-ttyPS0.device. // **here**

systemd only monitors for devices with "sysemd" tag. Tags are assigned
by udev rules. You should add rule to assign tag to ttyPS0. I have no
idea what it is, but something like

ACTION!="remove", KERNEL=="ttyPS0", TAG+="systemd"

should do it. Whether this should go upstream depends on how common
this device is.

> [DEPEND] Dependency failed for Serial Getty on ttyPS0. // **here**
> [  OK  ] Started Rebuild Hardware Database.
>  Starting Update is Completed...
>  Starting udev Kernel Device Manager...
> [  OK  ] Started Update is Completed.
> [  OK  ] Started udev Kernel Device Manager.
>
> I found there was a similar issue  
> https://github.com/systemd/systemd/issues/3446 which is on Ubuntu,  and 
> @jeras reported it can be fixed by 'apt get install udev' on Ubuntu, But on 
> Fedora 28 (Rawhide) and the latest version, I searched there is no udev 
> package now, there is only
> systemd-udev package, and the systemd-udev is installed. So  I didn't find a 
> way to fix this issue.
>
> **Steps to reproduce the problem**
> Boot the Fedora 28 (Rawhide) using Linux  kernel version 4.18 (or newer), 
> with kernel bootargs as below
> Kernel command line: console=ttyPS0,115200n8 root=/dev/mmcblk0p2 
> rootfstype=ext4 rw rootwait earlycon clk_ignore_unused
>
> Appreciate for any reply. Thanks in advance.
>
> Best,
> --
> Peng Zhou
> ___
> 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] [EXT] Re: Using timedatectl on a readonly rootfile system using mender

2020-09-12 Thread Andrei Borzenkov
09.09.2020 00:54, Alvin Šipraga пишет:
> Hi,
> 
> On 9/8/20 4:12 PM, Colin Guthrie wrote:
> 
>> 2. Set your /etc/ master image to make /etc/localtime to be a symlink to
>> /run/localtime and then ensure /run/localtime is a symlink to the
>> appropriate file in /usr during early boot (e.g. in initramfs). Then
>> when you want to to change the timezone, just update the /run/ symlink.
> 
> This might not work as expected - systemd sometimes assumes that
> /etc/localtime is a symlink into /usr/share/zoneinfo and will not
> understand double symlinks. See src/basic/time-util.c:get_timezone() for
> at least one example.
> 
> It's not too difficult to work around and I can provide a patch if
> anybody wants it, although I don't think it will safely deal with
> circular symlinks. 

Just add /var/state/tz (or any other suitable directory) to the
directory prefix list. The result is is not even needed to be symlink.

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


Re: [systemd-devel] Using timedatectl on a readonly rootfile system using mender

2020-09-05 Thread Andrei Borzenkov
05.09.2020 01:05, Lennart Poettering пишет:
> 
> I explained this already. DNS server data today is much less config
> than state, acquired dynamically via DHCP, hence most distros don#t
> configure it in /etc so much anymore, but manage it in /run (where
> transient state is generally kept), and only keep a compat symlink in
> /etc. If you try to convince people though that the local timezone
> should just be transient state and not persistent config you'll have a
> hard time. I for one am certainly not convinced that the timezones are
> state...
> 

Sorry? glibc has absolutely no problems with /etc/localtime being link
into /run, /var or whatever else (nor has it problems with this file
being normal file and not a link) as long as content of this file is
valid time zone definition. The only piece of software that has problem
with it is systemd. So may be you should stop finger pointing and simply
explain why *systemd* demands that /etc/localtime be specific symlink.

And yes, in current world this is state and not persistent config. When
I travel into another time zone I change state of my system for this
timezone. Just like DNS server address. Guess what? There is DHCP option
for time zone ... so how is it different from DNS server address?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Any published books on systemd? A cookbook?

2020-08-28 Thread Andrei Borzenkov
28.08.2020 17:47, Tom Browder пишет:
> I want to create a service file that has to consider other services. I have

What does it mean?

> looked at the man pages and probably don't have enough life expectancy to
> properly grok them.
> 

If you tell us what you try to achieve, someone may have an idea how to
express it using systemd.

> Can anyone point to a good book or cookbook for systemd?
> 
> Digital Ocean has the best I've found so far. Most "recipes" seem to be
> like Github's where each reads like an old Saturday morning movie serial as
> in "you've just found out how to write one line in one file. See my next
> article on how to write the second line of another file."
> 
> Best regards,
> 
> -Tom
> 
> 
> ___
> 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] A sh -c '${name} and $name' are treated inconsistently within a .service unit

2020-08-27 Thread Andrei Borzenkov
27.08.2020 19:11, u...@net9.ga пишет:
> Consider 
> 
> [Unit]
> Description=Is it looking for ${} construct in the wrong place?
> [Service]
> Type=oneshot
> ExecStart=/bin/bash -c 'set -x; declare -r str="1 2"; echo ${str}; echo $str; 
> exit 0;'
> 
> When ran, the journal has:
> 
> bash[14190]: + declare -r 'str=1 2'
> bash[14190]: + echo
> bash[14190]: + echo 1 2
> bash[14190]: 1 2
> bash[14190]: + exit 0
> 
> Note the top bash[14190]: + echo line. It has no arguments. Since the other 
> echo line
> has its 1 2 arguments, I find this behaviour inconsistent. And surprising. As 
> such, I
> think this is a bug.
> It could be that the ${NAME} construct is looked for in the environment. But 
> then, why 
> $NAME works in the script, but not ${NAME}?
> 

As documented $NAME is recognized only when used as separate word. The
string in quotes is single word; so ${str} inside it is recognized as
environment substitution and replaced by empty string but $str inside
the same word is left as is and later processed by shell.

> In addition, for the top bash[14190]: + echo line, isn't there a missing 
> empty, just
> [bash[14190]:, line?
> 
> Same results were obtained with systemd 241-7 and 246.2.
> 
> u34.
> ___
> 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] [Help] Can't log in to homed user account: "No space left on device"

2020-08-24 Thread Andrei Borzenkov
23.08.2020 09:34, Andrii Zymohliad пишет:
> Hello! I've lost the ability to log in to my systemd-homed user account. I 
> would be very grateful for any help!
> 
> If I log in as root and try to authenticate:
> 
> # homectl authenticate azymohliad
> 
> Then after typing my password I get the following output:
> 
> Operation on home azymohliad failed: Not enough disk space for home azymohliad
> 

...
> LUKS Discard: online=no offline=yes
...
> 
> My root partition is 475G, and as you can see, home file size is ~400G (I 
> guess it was stupid to leave only 75G for root in the first place). But for 
> some reason `btrfs fi usage /` shows that only 352G are allocated on the 
> device before I try to authenticate (every time after boot), and full 475G 
> after authentication attempt.


In discussion on btrfs list it was pointed out that btrfs fallocate by
design always tries to reserve space for full file size. So in this case
there are 123GB available which are not enough to reserve 400GB ...

https://lore.kernel.org/linux-btrfs/798a9077-bcbd-076c-a458-3403010ce...@libero.it/

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


Re: [systemd-devel] [Help] Can't log in to homed user account: "No space left on device"

2020-08-23 Thread Andrei Borzenkov
23.08.2020 15:34, Andrii Zymohliad пишет:
>> Here is the log after authentication attempt: 
>> https://gitlab.com/-/snippets/2007113
>> And just in case here is the full log since boot: 
>> https://gitlab.com/-/snippets/2007112
> 
> Sorry, links are broken, re-uploaded:
> 
> Authentication part: https://gitlab.com/-/snippets/2007123
> Full log: https://gitlab.com/-/snippets/2007124
> 

Yes, as suspected:

> сер 23 14:12:48 az-wolf-pc systemd-homed[917]: Not enough disk space
to fully allocate home.

This comes from

if (fallocate(backing_fd, FALLOC_FL_KEEP_SIZE, 0, st->st_size) <
0) {

...
if (ERRNO_IS_DISK_SPACE(errno)) {
log_debug_errno(errno, "Not enough disk space to
fully allocate home.");
return -ENOSPC; /* make recognizable */
}

return log_error_errno(errno, "Failed to allocate
backing file blocks: %m");
}

So fallocate syscall failed. Try manually

fallocate -l 403G -n /home/azymohliad.home

if it fails too, the question is better asked on btrfs list.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [Help] Can't log in to homed user account: "No space left on device"

2020-08-23 Thread Andrei Borzenkov
23.08.2020 09:34, Andrii Zymohliad пишет:
> Hello! I've lost the ability to log in to my systemd-homed user account. I 
> would be very grateful for any help!
> 
> If I log in as root and try to authenticate:
> 
> # homectl authenticate azymohliad
> 
> Then after typing my password I get the following output:
> 
> Operation on home azymohliad failed: Not enough disk space for home azymohliad
> 
> It also produces the following system logs:
> 
> сер 22 09:11:08 az-wolf-pc systemd-homed[425]: azymohliad: changing state 
> inactive → authenticating
> 
> сер 22 09:11:08 az-wolf-pc systemd-homework[1215]: None of the supplied 
> plaintext passwords unlocks the user record's hashed passwords.
> 
> сер 22 09:11:08 az-wolf-pc systemd-homed[425]: Authentication failed: 
> Required key not available
> 
> сер 22 09:11:08 az-wolf-pc systemd-homed[425]: azymohliad: changing state 
> authenticating → inactive
> 
> сер 22 09:11:23 az-wolf-pc systemd-homed[425]: azymohliad: changing state 
> inactive → authenticating
> 
> сер 22 09:11:23 az-wolf-pc systemd-homework[1216]: Provided password unlocks 
> user record.
> 
> сер 22 09:11:23 az-wolf-pc systemd-homed[425]: Authentication failed: No 
> space left on device
> 
> сер 22 09:11:23 az-wolf-pc systemd-homed[425]: azymohliad: changing state 
> authenticating → inactive
> 
> And here 
> [https://pastebin.com/BwkkvbZr](https://pastebin.com/BwkkvbZr]here[/url) is 
> the full log since the last boot.
> 
> My root filesystem is BTRFS, home is LUKS-encrypted BTRFS on a loopback file. 
> Here's the details:
> 
> # homectl inspect azymohliad
> 
> User name: azymohliad
> State: inactive
> Disposition: regular
> Last Change: Thu 2020-06-25 17:41:52 EEST
> Last Passw.: Thu 2020-06-04 19:04:43 EEST
> Login OK: yes
> Password OK: yes
> UID: 60265
> GID: 60265 (azymohliad)
> Aux. Groups: audio
> docker
> wheel
> Real Name: Andrii Zymohliad
> Directory: /home/azymohliad
> Storage: luks (strong encryption)
> Image Path: /home/azymohliad.home
> Removable: no
> Shell: /usr/bin/fish
> LUKS Discard: online=no offline=yes
...>
> My root partition is 475G, and as you can see, home file size is ~400G (I 
> guess it was stupid to leave only 75G for root in the first place). But for 
> some reason `btrfs fi usage /` shows that only 352G are allocated on the 
> device before I try to authenticate (every time after boot), and full 475G 
> after authentication attempt.

As far as I can tell if discards are disabled, systemd tries to allocate
full size of backing file. It is possible that there is simply not
enough space to ensure full 400G (i.e. available space it consumed by
something else). Are there are snapshots

Try enabling debug log level, this will give more details about what
happens.

> 
> I've posted some more btrfs info outputs on Arch forum 
> (https://bbs.archlinux.org/viewtopic.php?id=258382). I'm not sure how to 
> properly format snippets on mail list and how convenient it is to read them 
> here, first time on tech mail list.
> 
> I can unlock and mount my /home/azymohliad.home file manually, so that 
> confirms that it's not corrupted. I haven't tried to resize it manually 
> (outside of homectl), I'm afraid to do anything wrong.
> 
> Thanks for taking time to read this far! Is there anything obvious here that 
> I can do to fix it? Or any hints where to look?
> 
> 
> ___
> 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] Using timedatectl on a readonly rootfile system using mender

2020-08-20 Thread Andrei Borzenkov
20.08.2020 18:55, Shravan Singh пишет:
>  Hello,
> I have raspberry-pi cm3 which is running an embedded yocto poky linux
> warrior branch with mender.
> 
> I have made my rootfs as read-only because of which I am not able to use
> timedatectl to change the system time zone.
> 
> I was looking through the c code which makes me think that even if I did
> create and change symlink to point to a file in a read and write location
> of the memory. It won't make any difference.
> 

Changing timezone globally requires changing /etc/localtime link which
requires writable /etc.

> I looked into the file timedated.c and here is where I wanted some help. I
> see the line
> * r= get_timzeone()* in the function *context_read_data* all I want to know
> is where is *get_timezone* defined and how is it calling */etc/localtime*
> 

src/basic/time-util.c

grep is wonderful tool.

> Any help will be appreciated. I have raised questions everywhere and I am
> not getting any help at all.
> 
> And I am not an embedded developer. This place is my last cry for help
> Regards,
> Shravan Singh
> (239) 243-0838
> 
> Blue Sparq, Inc.
> 928 NE 24th Lane unit 4 and 5.
> Cape Coral, FL 33993
> 
> IMPORTANT: The contents of this email and any attachments are confidential.
> They are intended for the named recipient(s) only. If you have received
> this email by mistake, please notify the sender immediately and do not
> disclose the contents to anyone or make copies thereof.
> 
> 
> ___
> 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] fuse-sshfs and x-systemd.automount

2020-08-15 Thread Andrei Borzenkov
15.08.2020 23:56, Reindl Harald пишет:
> is it a bug or a concept issue that it's mounted fpr root instead auf
> the user given with uid or is there just a param i am not aware mising?
> 

allow_other

how is it relevant to systemd?

> there are 20 mountpoints of that style and automount would be really cool
> 
> i wouldn't even mind if touching by root would mount it for mewith root
> having no access as expected for fuse-mounts of that style
> 
> they are all excluded for mlocate
> 
> ---
> 
> sshfs#reindl@arrakis:/ /mnt/arrakis fuse
> noauto,user,rw,noexec,nosuid,nodev,noatime,uid=harry,gid=verwaltung,x-systemd.automount
> 
> ---
> 
> Aug 15 22:43:46 srv-rhsoft systemd[1]: Set up automount
> mnt-arrakis.automount.
> Aug 15 22:43:51 srv-rhsoft systemd[1]: mnt-arrakis.automount: Got
> automount request for /mnt/arrakis, triggered by 47290 (ls)
> Aug 15 22:43:51 srv-rhsoft systemd[1]: Mounting /mnt/arrakis...
> Aug 15 22:43:51 srv-rhsoft kernel: fuse: init (API version 7.31)
> Aug 15 22:43:51 srv-rhsoft systemd[1]: Mounting FUSE Control File System...
> Aug 15 22:43:51 srv-rhsoft systemd[1]: Mounted FUSE Control File System.
> Aug 15 22:43:52 srv-rhsoft systemd[1]: Mounted /mnt/arrakis.
> 
> [root@srv-rhsoft:~]$ df
> Dateisystem  TypGröße Benutzt Verf. Verw% Eingehängt auf
> /dev/md1 ext4 29G7,6G   22G   27% /
> /dev/md2 ext43,6T1,2T  2,5T   33% /mnt/data
> reindl@arrakis:/ fuse.sshfs  126G 58G   68G   47% /mnt/arrakis
> 
> [harry@srv-rhsoft:~]$ df
> DateisystemTyp  Größe Benutzt Verf. Verw% Eingehängt auf
> /dev/md1   ext4   29G7,6G   22G   27% /
> /dev/md2   ext4  3,6T1,2T  2,5T   33% /mnt/data
> [harry@srv-rhsoft:~]$
> 
> ---
> 
> Expected:
> 
> [harry@srv-rhsoft:~]$ df
> Dateisystem  TypGröße Benutzt Verf. Verw% Eingehängt auf
> /dev/md1 ext4 29G7,6G   22G   27% /
> /dev/md2 ext43,6T1,2T  2,5T   33% /mnt/data
> reindl@arrakis:/ fuse.sshfs  126G 58G   68G   47% /mnt/arrakis
> ___
> 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: [EXT] I/O error on "systemctl kill -s HUP rsyslog.service"

2020-08-13 Thread Andrei Borzenkov
13.08.2020 09:54, Harald Dunkel пишет:
> On 8/12/20 2:16 PM, Andrei Borzenkov wrote:
>> 12.08.2020 14:03, Harald Dunkel пишет:
>>> See attachment. Hope this helps
>>> Harri
>>
>>
>>> 1 openat(AT_FDCWD,
>>> "/sys/fs/cgroup/unified/system.slice/rsyslog.service/cgroup.procs",
>>> O_RDONLY|O_CLOEXEC) = 24
>>> 1 read(24, "0\n1544456\n", 4096)    = 10
>>
>>
>> kernel returns "0" as process number in this cgroup which results in EIO
>> returned by systemd.
> 

systemd should really clearly log this (invalid PID and and in which
cgroup it was). Returning generic error message without any indication
what caused this error is not useful at all.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Antw: [EXT] I/O error on "systemctl kill -s HUP rsyslog.service"

2020-08-12 Thread Andrei Borzenkov
12.08.2020 14:03, Harald Dunkel пишет:
> See attachment. Hope this helps
> Harri


> 1 openat(AT_FDCWD, 
> "/sys/fs/cgroup/unified/system.slice/rsyslog.service/cgroup.procs", 
> O_RDONLY|O_CLOEXEC) = 24
> 1 read(24, "0\n1544456\n", 4096)= 10


kernel returns "0" as process number in this cgroup which results in EIO
returned by systemd.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Antw: [EXT] I/O error on "systemctl kill -s HUP rsyslog.service"

2020-08-12 Thread Andrei Borzenkov
12.08.2020 13:04, Harald Dunkel пишет:
> On 8/12/20 10:32 AM, Ulrich Windl wrote:
>>
>> As you found out the details already, maybe you could have added some
>> strace
>> output, especially after the kill() is returning...
>>
> 
> See attachment. Hope this helps

Not really. We already know that systemctl gets error from systemd. You
need to strace systemd when it tries to perform requested operation.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] ConditionPathExists vs mount unit

2020-08-11 Thread Andrei Borzenkov
10.08.2020 20:59, Böszörményi Zoltán пишет:
> Hi,
> 
> I have to use the same OS image tarball (created by Yocto)
> on several machines with different specifications.
> 
> Where they differ is the disk size and partitioning. On the smaller
> machine (a Sicom SL20 POS hardware, boots from CF card) the disk size
> is too small to have separate partitions for certain purposes that are
> on the other hand mandatory on the larger system.
> 
> The shipped disks are mass-produced and are pre-formatted with
> the same UUIDs across all devices so they are interchangeable.
> 
> So, I discovered the mount unit type:
> https://www.freedesktop.org/software/systemd/man/systemd.mount.html
> 
> This page says that the usual [Unit] section options are applicable.
> 
> I was hoping that the missing partitions can be skipped using the
> ConditionPathExists= option but it seems it's not the case.
> 
> On mount unit looks like this:
> 
> $ cat var.mount
> [Unit]
> Description=Variable Data (/var)
> ConditionPathExists=/dev/disk/by-uuid/e8282db7-dd6d-4231-b2b1-49887648480c
> ConditionPathIsSymbolicLink=!/var
> DefaultDependencies=no
> Conflicts=umount.target
> Before=local-fs.target umount.target
> After=swap.target
> 
> [Mount]
> What=/dev/disk/by-uuid/e8282db7-dd6d-4231-b2b1-49887648480c
> Where=/var
> Options=noatime
> 
> [Install]
> WantedBy=local-fs.target
> 
> 
> This boots properly on the larger system where the extra /var
> partition exists but the smaller system fails to boot.
> 
> systemctl status var.mount says:
> 
> Dependency failed for Variable Data (/var)
> var.mount: Job var.mount/start failed with result 'dependency'
> 
> Is there a way to describe optional mounts via such Conditions* options?
> 

No the way you are doing it. Device dependency is checked before
Conditions* directives are even looked at.

If your concern is only boot time, you should consider generators that
will create correct mount units for currently present hardware.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd unit timer

2020-08-09 Thread Andrei Borzenkov
09.08.2020 13:40, Vini Harimoorthy пишет:
> In that case, it will run only in Oct,Nov, & Dec. But, I want to run the
> timer unit weekly after a specific calendar date & time.
> How to specify if I want to run some task on every 12 hours after Jan'2021
> (start from future date & time)
> 

That's not possible using systemd timer as of now. There was similar
discussion just recently (a week or two ago).
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd.timer every X days?

2020-07-27 Thread Andrei Borzenkov
26.07.2020 22:56, Ian Pilcher пишет:
> My NAS has 16 MD RAID devices.  I've created a simple service
> (raidcheck@.service) that will trigger a check of the RAID device
> identified by the argument.  E.g., 'systemctl start raidcheck@md1' will
> trigger the check of md1 (after checking that no other array is being
> checked/synced, no arrays are degraded, etc.).
> 
> It takes 6-8 hours to check one of these arrays, so I want to run one
> check every night at 23:00.  So (picking tonight as an arbitrary
> starting point) md1 would run tonight, md2 would run tomorrow night, md3
> would run the following night ... all the way through md16.  Then the
> cycle would start over with md1.
> 
> I had thought that I would be able to create 16 separate timers (one for
> each device), each scheduled to trigger every 16 days at 23:00, starting
> on a particular day.
> 
> Looking through the systemd.timer(5) and systemd.time(7) man pages,
> however, I haven't been able to figure out how to do this.  Is it not
> possible, or am I missing something?
> 

Not using native timer syntax. Repetition is really shorthand for list
of values in the same period (i.e. 2020-07-03/16 is just short form of
2020-07-03,19); it does not mean "repeat every 16 days from now on".

You could have boot time service that creates 16 timers with something like

systemd-run --on-calendar=first-date-and-time-for-this-timer
--on-unit-active=16days --unit=your.service

This could also be generator, but it also runs on every daemon-reload
which happens quite often.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Can service of timers.target having After=multi-user.target create a loop?

2020-07-12 Thread Andrei Borzenkov
12.07.2020 23:37, Uoti Urpala пишет:
> On Sun, 2020-07-12 at 17:13 +0300, Andrei Borzenkov wrote:
>> 12.07.2020 16:21, Amish пишет:
>>> I have a timer file like this:
>>>
>>> [Unit]
>>> Description=Foo
>>> After=multi-user.target
>>>
>>> [Timer]
>>> OnCalendar=*:0/5
>>> Persistent=false
>>>
>>> [Install]
>>> WantedBy=timers.target
> 
> 
>>> Because AFAIK timers.target runs before multi-user.target. But here
>>> something inside timers.target waits for multi-user.target.
>>>
>>> So how does systemd resolve this loop?
>>>
>>
>> There is no loop. There is no transitive dependency between timer unit
>> and service unit. Timer unit gets started early and enqueues start job
>> for service unit; this start job waits for multi-user.target according
>> to After dependency. Mulitple invocation of timer will try enqueue start
>> job again which will simply be merged with existing pending request.
> 
> But shouldn't the After line be in the .service file, not the timer, in
> this case? The timer should be ready early if it's activated by
> timers.target, the service should wait before running.
> 

Sorry, I did not pay attention.

In this case there is no loop as well, because timers.target itself does
not have any Before dependencies by default. So timer.target becomes
active after multi-user.target but it does not really affect anything.
In particular other timers will be activated as soon as possible, they
won't be delayed until timers.target is active.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd-journald, syslog.socket and service activation

2020-07-12 Thread Andrei Borzenkov
03.07.2020 12:09, Thomas HUMMEL пишет:
> 
> 
> On 02/07/2020 20:48, Andrei Borzenkov wrote:
> 
> 
>> Once again - dependencies in systemd are between jobs, not between units.
> 
> Ok. I may have missed some docs but I've read several man sections
> (likesystemd.service(5) and so on) as well as some 0pointer blog
> articles) and I did experiment a lot.
> I did not see this explained as clearly as you do here. At the opposite
> it tends to focus on units (at least that's how I've read it the first
> time), hence the confusion ? In fact, when reading those for the first
> time I was left wanting to know more about transactions and jobs (which
> are mentioned but really quickly). [Note that this is by no way a
> criticism, just a/my feedback]. Watching debug logs gave me hints but
> were not sufficient to come to the understanding you give me right now.
> 

systemd was designed to perform one single task - start well defined
collection of units during system boot. When you consider this, it does
not really matter whether you talk about unit or job dependency, end
result is the same. I sincerely hope it was honest self delusion and not
deliberate marketing trick to facilitate acceptance.

Later systemd became abused as dynamic service manager, misleading
documentation played not the last role in it. This thread is typical
example.

>> Rule 1: "B requires A" means "when starting B also submit start job for
>> A and if this job failed *before we start activating B* cancel
>> activation of B". If there is already start job for A for other reasons,
>> the first part does nothing.
> 
> Ok. What could be other reasons and do you mean this other reason would
> itself have already added the A dependency and its management for itself ?
> 

Unit could have been started (or at least requested to be started) due
to dependencies of other units.

>>
>> Rule 2: "B after A" means "if start job for A is present in job queue
>> wait for this job to complete before proceeding with start job for B".
>>
>> In your case on boot you have general Before dependency syslog.socket -
>> sockets.target - basic.target - rsyslog.service and start request for
>> both syslog.socket and rsyslog.service are queued. Start job for
>> rsyslog.service is always delayed at least after basic.target (rule 2).
>> At this point systemd already tried and failed to start syslog.socket,
>> so rule 1 applies.
> 
> Ok. So I guess my test when I, after reboot, run 4 ou 5 systemctl start
> rsyslog.service and only the last one succeeds corresponds to this "race
> condition" you described above ?
> 

Yes.

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


Re: [systemd-devel] Can service of timers.target having After=multi-user.target create a loop?

2020-07-12 Thread Andrei Borzenkov
12.07.2020 16:21, Amish пишет:
> Hello,
> 
> This is a question out of curiosity and not currently any problem.
> 
> I have a timer file like this:
> 
> [Unit]
> Description=Foo
> After=multi-user.target
> 
> [Timer]
> OnCalendar=*:0/5
> Persistent=false
> 
> [Install]
> WantedBy=timers.target
> 
> And corresponding service file like this:
> 
> [Unit]
> Description=Foo
> 
> [Service]
> Type=oneshot
> ExecStart=-/usr/bin/checkservices
> 
> /usr/bin/checkservices checks if some important services are running and
> sends alert if not.
> 
> Above timer is supposed to run every five minutes. But not while system
> is still booting.
> 
> If I do not put After=multi-user.target then timer gets triggered even
> before those services have begun (while booting) and sends false alarm.
> 
> With above settings, I do not face that issue.
> 
> But just out of curiosity I am eager to know if this or something
> similar can cause loop and hang system forever from booting?
> 
> Because AFAIK timers.target runs before multi-user.target. But here
> something inside timers.target waits for multi-user.target.
> 
> So how does systemd resolve this loop?
> 

There is no loop. There is no transitive dependency between timer unit
and service unit. Timer unit gets started early and enqueues start job
for service unit; this start job waits for multi-user.target according
to After dependency. Mulitple invocation of timer will try enqueue start
job again which will simply be merged with existing pending request.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd-journald, syslog.socket and service activation

2020-07-02 Thread Andrei Borzenkov
02.07.2020 21:28, Thomas HUMMEL пишет:
> 
> 
> On 02/07/2020 19:00, Andrei Borzenkov wrote:
> 
>> After=syslog.socket will exist only if rsyslog.service is aliased to
>> syslog.service and your problem was when you removed this alias.
> 
> Correct (I did miss this simple thing) !
> 
> 
>> On boot activation of syslog.socket happens much earlier than activation
>> of rsyslog.service which gives systemd enough time to register failure
>> of syslog.socket.
> 
> 
> hmmm, but since like you said above the After dependency was not taken
> into account as there is no alias, registering failure should not
> prevent rsyslog to be activated (at boot, it end up being dead) ?
> 
>> When you start them manually both jobs are submitted
>> at the same time so activation of rsyslog.service has already happened
>> when activation of syslog.socket fails. It is already too late for "this
>> unit will not be started".
> 
> I didn't though indeed about these timing diffrences but, again, without
> the After= having any effect, it should not matter, should it ?
> 
> 
> So I'm still convinces I'm missing something obvious...
> 

It is by far not obvious unfortunately.

Once again - dependencies in systemd are between jobs, not between units.

Rule 1: "B requires A" means "when starting B also submit start job for
A and if this job failed *before we start activating B* cancel
activation of B". If there is already start job for A for other reasons,
the first part does nothing.

Rule 2: "B after A" means "if start job for A is present in job queue
wait for this job to complete before proceeding with start job for B".

In your case on boot you have general Before dependency syslog.socket -
sockets.target - basic.target - rsyslog.service and start request for
both syslog.socket and rsyslog.service are queued. Start job for
rsyslog.service is always delayed at least after basic.target (rule 2).
At this point systemd already tried and failed to start syslog.socket,
so rule 1 applies.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd-journald, syslog.socket and service activation

2020-07-02 Thread Andrei Borzenkov
02.07.2020 18:57, Thomas HUMMEL пишет:
> 
> 
> On 02/07/2020 16:44, Andrei Borzenkov wrote:
> 
>> This is common misunderstanding. Dependencies are between jobs, not
>> between units. Requires means systemd will submit additional job for
>> dependent unit - nothing more nothing less. Unless systemd is also told
>> to wait for result of this additional job, both are started in parallel
>> and failure of dependent job does not affect other unit in any way.
> 
> You're right. Sorry if I was not clear.
> Note however that systemd.unit doc talks about units, not jobs for
> Requires=
> 
> Anyway, it turns out that systemctl list-dependencies --after
> rsyslog.service shows also an ordering dependency on sockets.target /
> syslog.socket.
> 
> So, I might be wrong but shouldn't Requires= + After= make the rsyslog
> service fail if syslog.socket fails ?
> 
> # systemctl show -p Requires,After rsyslog.service
> Requires=syslog.socket system.slice sysinit.target
> After=system.slice sysinit.target syslog.socket network.target
> basic.target network-online.target
> 

After=syslog.socket will exist only if rsyslog.service is aliased to
syslog.service and your problem was when you removed this alias.

> Doc says:
> "If this unit gets activated, the units listed will be activated as
> well. If one of the other units fails to activate, and an ordering
> dependency After= on the failing unit is set, this unit will not be
> started. "
> 
> That's what I meant and though it does seems so at boot, I seemed to
> experience the contrary when manually starting rsyslog.service...
> 

On boot activation of syslog.socket happens much earlier than activation
of rsyslog.service which gives systemd enough time to register failure
of syslog.socket. When you start them manually both jobs are submitted
at the same time so activation of rsyslog.service has already happened
when activation of syslog.socket fails. It is already too late for "this
unit will not be started".
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd-journald, syslog.socket and service activation

2020-07-02 Thread Andrei Borzenkov
02.07.2020 16:09, Thomas HUMMEL пишет:
> 
> [Unit]
> Requires=syslog.socket
> 
> [Install]
> ;Alias=syslog.service
> 
...
> 
> # systemctl start rsyslog
> A dependency job for rsyslog.service failed. See 'journalctl -xe' for
> details.
> 
> BUT rsyslog service (and daemon) are actually running:
> 
>    Active: active (running) since Thu 2020-07-02 14:45:37 CEST; 2min 10s
> ago
> 
...
> Question 1:
> 
>  How is it that despite a Requires= not satisfied the service is run
> (and that this behavior is different at boot time) ?

This is common misunderstanding. Dependencies are between jobs, not
between units. Requires means systemd will submit additional job for
dependent unit - nothing more nothing less. Unless systemd is also told
to wait for result of this additional job, both are started in parallel
and failure of dependent job does not affect other unit in any way.

I'm yet to see use case where Requires without After makes sense to
justify this implementation.

> 
> Question 2:
> ---
> 
> Where (is it hard coded) can I get the info telling me that
> syslog.socket unit can socket-activate the syslog.service (hence the
> need of the Alias I guess) ?

By default foo.socket activates foo.service. This is actually documented
in "man systemd.socket".

> 
> Question 3:
> 
> 
> I can also issue, right after boot several systemctl start rsyslog
> command. The first few ones will print the 'A dependency job for
> rsyslog.service failed. See 'journalctl -xe' for details.' message, but
> ultimately, the last one will launch rsyslog service without any message :
> 
> # systemctl start rsyslog
> A dependency job for rsyslog.service failed. See 'journalctl -xe' for
> details.
> # systemctl start rsyslog
> A dependency job for rsyslog.service failed. See 'journalctl -xe' for
> details.
> # systemctl start rsyslog
> A dependency job for rsyslog.service failed. See 'journalctl -xe' for
> details.
> # systemctl start rsyslog
> A dependency job for rsyslog.service failed. See 'journalctl -xe' for
> details.
> # systemctl start rsyslog
> #
> 
> rsyslog service will end up running but still no syslog journald socket
> (which seems normal considering the dependency but weird as I did not
> have any message about it at the last start command)
> 
> # ls -l /run/systemd/journal/syslog
> ls: cannot access '/run/systemd/journal/syslog': No such file or directory
> 
> 
> What am I missing ?
> 
> Note: rsyslog service is of Type notify and has a Restart value of no-fail
> 
> Thanks for your help
> 
> -- 
> Thomas HUMMEL
> 
> 
> 
> ___
> 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] Ensuring that a unit starts before any networking

2020-06-27 Thread Andrei Borzenkov
27.06.2020 13:42, Mark Rogers пишет:
> On Sat, 27 Jun 2020 at 11:06, Zbigniew Jędrzejewski-Szmek
>  wrote:
>> You should use Before=network-pre.target, Wants=network-pre.target.
> 
> Thanks, tried that but still not working:
> 

All other units that implement networking must have
After=network-pre.target for the above to do anything. Do they?

> $ journalctl -b | grep -Ei '(db2config|dhcpcd)'
> Feb 14 10:12:03 localhost systemd[1]: Starting dhcpcd on all interfaces...
> Feb 14 10:12:03 localhost dhcpcd[341]: read_config: fopen
> `/etc/dhcpcd.conf': No such file or directory
> [...]
> Jun 27 10:19:39 localhost dhcpcd[341]: wlan0: /etc/wpa_supplicant.conf
> does not exist
> [...]
> Jun 27 10:19:39 localhost dhcpcd[341]: read_config: fopen
> `/etc/dhcpcd.conf': No such file or directory
> [...]
> Jun 27 10:19:40 localhost dhcpcd[341]: eth0: soliciting an IPv6 router
> Jun 27 10:19:40 localhost dhcpcd[341]: eth0: soliciting a DHCP lease
> Jun 27 10:19:41 mypi db2config.py[325]: 2020-06-27 10:19:41 db2config
> Creating /tmp/sys//etc/dhcpcd.conf
> Jun 27 10:19:41 mypi db2config.py[325]: 2020-06-27 10:19:41 db2config
> Creating /tmp/sys//etc/wpa_supplicant/wpa_supplicant.conf
> 
> (Comments about that extract: the jump from Feb to Jun I assume is the
> clock getting updated from RTC, it's all from the same boot obviously;
> also note my db2config script doesn't run until after hostname is set
> which I would assume is set by the network startup?)
> 
> Unit file is currently:
> 
> [Unit]
> Description=Config generation from DB
> Before=network-pre.target
> Wants=network-pre.target
> 
> [Service]
> Type=oneshot
> ExecStart=/home/mark/bin/db2config.py
> 
> [Install]
> RequiredBy=network.target
> 
> After any changes I'm using
> $ sudo systemctl daemon-reload
> $ sudo systemctl reenable db2config.service
> 
> ... although that's another area I'm not entirely clear about what
> exactly is required after a unit file change.
> 
> PS: Is list etiquette around here to CC on reply? Some love it, some
> hate it, others don't care...
> 
> 
> --
> Mark Rogers
> ___
> 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] Systemd killed processes of custom services instead of graceful shutdown

2020-06-19 Thread Andrei Borzenkov
18.06.2020 10:07, Kamal Rathi пишет:
> 
> Now I am more eager to know if is it possible to run anything before it
> kills users processes  at shutdown / reboot / halt.

User processes run either as part of user session or as part of user
service. The former is session-xxx.scope, the latter is
user@UID.service. You could add Before=your.service to user@.service
template to make sure your.service is stopped first. Current version of
systemd allows creation of drop-ins in session-.scope.d as well to add
dependency to all session scopes. Check systemd.unit man page.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Systemd killed processes of custom services instead of graceful shutdown

2020-06-16 Thread Andrei Borzenkov
17.06.2020 07:46, Kamal Rathi пишет:
>> Please take at least some efforts to format mail so that it can be
>> properly understood. Otherwise I am afraid your mails will simply be
>> ignored.
> 
>I am sorry for inconvenience, i will try to follow correct approach
> afterwards while replying
> 
>> How RemainAfterExit affects *startup* of services?
> 
>   The services worked as expected and as i fixed the issue where it was
> using su in script.
>   As in background there was SysVinit script which was getting invoked
> when system boot and makes processes falls in users.slice
>   So the startup is working perfectly after disabling that SysVinit
> script.
> 
>> So I was right. Your programs are running as user services or part of
>> user sessions.
> 
>  You were absolutely right, I tried to dig into that and find out as it
> was using internally su,
>  but now only problem remains is shutdown order.
>  As I have created a dependency that rdbms.service should start after
> grid.service which works perfect at boot.
> But when I do shutdown / reboot both services stop simultaneously.
> which i want my grid.service to wait first before rdbms.service will
> stop
> As Type mentioned in services are oneshot.
> 
>> dmesg output does not contain any systemd log. Anyway, we already know
>> that your services are not really system services.
> 
> So my service is system services, as let me attach cgls output
> 
> └─system.slice
>  ├─rdbms.service
>  │ └─8039 /sarahn9db/db/11.2.0/bin/tnslsnr sarahn9 -inherit
>  ├─grid.service
>  │ ├─  5316 /grid/gi/11.2.0/bin/ohasd.bin reboot
>  │ ├─  6159 /grid/gi/11.2.0/bin/cssdagent
> 

The obvious possibilities

- ExecStop command returns before application is actually stopped.
ExecStop must be synchronous, systemd assumes service is stopped when
ExecStop command completes

- stopping takes longer then TimeoutStopSec

- your actual database it still started outside of rdbms.service. The
only process shown in your output is listener, but I would expect rather
more of Oracle there

Without logs it is impossible to say anything more specific.


> On Tue, Jun 16, 2020 at 12:23 AM Andrei Borzenkov 
> wrote:
> 
>> 16.06.2020 07:36, Kamal Rathi пишет:
>>> The fact that you need RemainAfterExit at all hints that processes that
>>> belong to your service are not running as part of service control group.
>>> Knowing how Oracle has traditionally been managed, I suspect that you
>>> perform "su - oracle_owner" or similar to start them in which case all
>>> actual service processes become part of respective user sessions, and
>>> not part of your system services. There is no way to synchronize
>>> stopping of processes/services belonging to different users. They are
>>> completely independent and shutdown for all sessions is initiated in
>>> parallel.
>>>
>>
>> Please take at least some efforts to format mail so that it can be
>> properly understood. Otherwise I am afraid your mails will simply be
>> ignored.
>>
>>> If my theory is correct, the fix would be to actually run your systemd
>>> services as systemd services. If my theory is wrong, provide full from
>>> system boot to shutdown where it could be seen how your services are
>>> started/stopped. Enabling systemd debug log level when doing it
>>> certainly won't harm.
>>>
>>>
>>>
>>> I have incorporated Type=oneshot and remainAfterExit=yes as it was
>> helpful
>>> in startup of services,
>>
>>
>> How RemainAfterExit affects *startup* of services?
>>
>>> but still grid.service are starting up in
>>> user.slice
>>
>> So I was right. Your programs are running as user services or part of
>> user sessions.
>>
>>> and shutdown was giving the same results
>>> I am attaching debug logs .
>>>
>>
>> dmesg output does not contain any systemd log. Anyway, we already know
>> that your services are not really system services.
>>
>>> On Mon, Jun 15, 2020 at 10:34 AM Andrei Borzenkov 
>>> wrote:
>>>
>>>> 15.06.2020 11:01, Kamal Rathi пишет:
>>>>> Hi Team,
>>>>>
>>>>> I have two services which are dependent on each other and are working
>>>> fine
>>>>> at boot up but at shutdown / reboot , the processes get killed as
>>>> shutdown
>>>>> got initated.
>>>>>
>>>>> Services are running fine in particular order but processes got killed
>> .I
>>

Re: [systemd-devel] Systemd killed processes of custom services instead of graceful shutdown

2020-06-15 Thread Andrei Borzenkov
16.06.2020 07:36, Kamal Rathi пишет:
> The fact that you need RemainAfterExit at all hints that processes that
> belong to your service are not running as part of service control group.
> Knowing how Oracle has traditionally been managed, I suspect that you
> perform "su - oracle_owner" or similar to start them in which case all
> actual service processes become part of respective user sessions, and
> not part of your system services. There is no way to synchronize
> stopping of processes/services belonging to different users. They are
> completely independent and shutdown for all sessions is initiated in
> parallel.
> 

Please take at least some efforts to format mail so that it can be
properly understood. Otherwise I am afraid your mails will simply be
ignored.

> If my theory is correct, the fix would be to actually run your systemd
> services as systemd services. If my theory is wrong, provide full from
> system boot to shutdown where it could be seen how your services are
> started/stopped. Enabling systemd debug log level when doing it
> certainly won't harm.
> 
> 
> 
> I have incorporated Type=oneshot and remainAfterExit=yes as it was helpful
> in startup of services,


How RemainAfterExit affects *startup* of services?

> but still grid.service are starting up in
> user.slice 

So I was right. Your programs are running as user services or part of
user sessions.

> and shutdown was giving the same results
> I am attaching debug logs .
> 

dmesg output does not contain any systemd log. Anyway, we already know
that your services are not really system services.

> On Mon, Jun 15, 2020 at 10:34 AM Andrei Borzenkov 
> wrote:
> 
>> 15.06.2020 11:01, Kamal Rathi пишет:
>>> Hi Team,
>>>
>>> I have two services which are dependent on each other and are working
>> fine
>>> at boot up but at shutdown / reboot , the processes get killed as
>> shutdown
>>> got initated.
>>>
>>> Services are running fine in particular order but processes got killed .I
>>> have enabled lingering on both users and changed confgiuration in
>>> logind.conf to KillUserProcesses=no but still issue is same
>>>
>>
>> Lingering/KillUserProcesses are relevant only for user services/sessions
>> and so far there was no indication you use either.
>>
>>> ##
>>> Systemd service files content are below
>>>
>>> cat /etc/systemd/system/grid.service
>>> [Unit]
>>> Description=Service to auto start Oracle ASM application
>>> Before=rdbms.service
>>> After=syslog.target network.target nfs-mountd.service autofs.service
>>> systemd-user-sessions.service system.slice
>>> [Service]
>>> Type=simple
>>> TimeoutSec=5min
>>> User=grid
>>> Group=dba
>>> ExecStart=/opt/admin/bin/asm
>>> ExecStop=/opt/admin/bin/asm_stop
>>> RemainAfterExit=yes
>>> [Install]
>>> WantedBy=multi-user.target
>>>
>>>
>>>
>>> cat /etc/systemd/system/rdbms.service
>>> [Unit]
>>> Description=Service to auto start Oracle RDBMS application
>>> Requires=grid.service
>>> After=grid.service syslog.target network.target nfs-mountd.service
>>> autofs.service systemd-user-sessions.service system.slice
>>> [Service]
>>> Type=simple
>>> TimeoutSec=5min
>>> User=osarahn9
>>> Group=dba
>>> ExecStart=/opt/admin/bin/rdbms
>>> ExecStop=/opt/admin/bin/rdbms_stop
>>> RemainAfterExit=yes
>>> [Install]
>>> WantedBy=multi-user.target grid.service
>>>
>>>
>>> let me know if my configuration is faulty or what I have missed so that
>>> shutdown should be graceful for services and processes will be
>>> shutdown with systemd custom service?
>>>
>>
>> You do not provide enough information (full logs would be certainly much
>> more useful than long description) so I can only give educated guess.
>>
>>> I want first rdbms.service should be called and get process stopped
>> before
>>> grid.services (it seems systemd are killing user.slices processes) and in
>>> startup-inverse should be followed .
>>> Please help .
>>>
>>
>> The fact that you need RemainAfterExit at all hints that processes that
>> belong to your service are not running as part of service control group.
>> Knowing how Oracle has traditionally been managed, I suspect that you
>> perform "su - oracle_owner" or similar to start them in which case all
>> actual service processes become part of respective 

Re: [systemd-devel] Systemd killed processes of custom services instead of graceful shutdown

2020-06-15 Thread Andrei Borzenkov
15.06.2020 11:01, Kamal Rathi пишет:
> Hi Team,
> 
> I have two services which are dependent on each other and are working fine
> at boot up but at shutdown / reboot , the processes get killed as shutdown
> got initated.
> 
> Services are running fine in particular order but processes got killed .I
> have enabled lingering on both users and changed confgiuration in
> logind.conf to KillUserProcesses=no but still issue is same
> 

Lingering/KillUserProcesses are relevant only for user services/sessions
and so far there was no indication you use either.

> ##
> Systemd service files content are below
> 
> cat /etc/systemd/system/grid.service
> [Unit]
> Description=Service to auto start Oracle ASM application
> Before=rdbms.service
> After=syslog.target network.target nfs-mountd.service autofs.service
> systemd-user-sessions.service system.slice
> [Service]
> Type=simple
> TimeoutSec=5min
> User=grid
> Group=dba
> ExecStart=/opt/admin/bin/asm
> ExecStop=/opt/admin/bin/asm_stop
> RemainAfterExit=yes
> [Install]
> WantedBy=multi-user.target
> 
> 
> 
> cat /etc/systemd/system/rdbms.service
> [Unit]
> Description=Service to auto start Oracle RDBMS application
> Requires=grid.service
> After=grid.service syslog.target network.target nfs-mountd.service
> autofs.service systemd-user-sessions.service system.slice
> [Service]
> Type=simple
> TimeoutSec=5min
> User=osarahn9
> Group=dba
> ExecStart=/opt/admin/bin/rdbms
> ExecStop=/opt/admin/bin/rdbms_stop
> RemainAfterExit=yes
> [Install]
> WantedBy=multi-user.target grid.service
> 
> 
> let me know if my configuration is faulty or what I have missed so that
> shutdown should be graceful for services and processes will be
> shutdown with systemd custom service?
> 

You do not provide enough information (full logs would be certainly much
more useful than long description) so I can only give educated guess.

> I want first rdbms.service should be called and get process stopped before
> grid.services (it seems systemd are killing user.slices processes) and in
> startup-inverse should be followed .
> Please help .
> 

The fact that you need RemainAfterExit at all hints that processes that
belong to your service are not running as part of service control group.
Knowing how Oracle has traditionally been managed, I suspect that you
perform "su - oracle_owner" or similar to start them in which case all
actual service processes become part of respective user sessions, and
not part of your system services. There is no way to synchronize
stopping of processes/services belonging to different users. They are
completely independent and shutdown for all sessions is initiated in
parallel.

If my theory is correct, the fix would be to actually run your systemd
services as systemd services. If my theory is wrong, provide full from
system boot to shutdown where it could be seen how your services are
started/stopped. Enabling systemd debug log level when doing it
certainly won't harm.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Antw: [EXT] Re: Q: ypbind-systemd-pre[1756]: \nError: NIS domain not specified.\n

2020-06-04 Thread Andrei Borzenkov
On Thu, Jun 4, 2020 at 9:05 AM Ulrich Windl
 wrote:
>
> But if so, why would it be started if that service is disabled?

Because "disabled" in systemd just means that links in the [Install]
section have not been created. It does not mean "this unit won't be
started under any circumstances".

...

> So some script may have started the service manually. I wonder: How
> complicated and efficient would it be if "systemctl status" would output the
> reason (e.g.: "manual|dependency") for the last service start (or maybe even
> stop)?
>

Enabled unit is started by dependency as well. There is no difference.
"enabled" means exactly "add dependency to another unit"; it is not
distinguishable from "other unit has dependency on this unit".

There is systemctl list-dependencies which may help.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Q: ypbind-systemd-pre[1756]: \nError: NIS domain not specified.\n

2020-05-28 Thread Andrei Borzenkov
28.05.2020 16:43, Ulrich Windl пишет:
> Hi!
> 
> Monitoring the messages created when booting SLES12 SP5, I noticed these:
> 
> ypbind-systemd-pre[1756]: \nError: NIS domain not specified.\n
> systemd[1]: ypbind.service: Control process exited, code=exited status=1
> systemd[1]: Failed to start NIS/YP Clients to NIS Domain Binder.
> systemd[1]: ypbind.service: Unit entered failed state.
> systemd[1]: ypbind.service: Failed with result 'exit-code'.
> systemd[1]: Reached target User and Group Name Lookups.
> 
> The interesting point is that ypbind.service is disabled. So why is 
> ypbind-systemd-pre complaining about NIS domain not being set?
> 

And how exactly ypbind-systemd-pre is related to ypbind.service?

> (systemd-228-157.9.1.x86_64)
> 
> 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


Re: [systemd-devel] systemd-networkd, IPv6PrivacyExtensions=kernel, sysctl and devicenames

2020-05-23 Thread Andrei Borzenkov
23.05.2020 11:56, Ede Wolf пишет:
>>
>> tw:~ # systemctl stop NetworkManager.service
>> tw:~ # ip l set dev enp0s5 down
>> tw:~ # cat /proc/sys/net/ipv6/conf/enp0s5/use_tempaddr
>> 1
>> tw:~ # cat /proc/sys/net/ipv6/conf/enp0s5/addr_gen_mode
>> 1
>> tw:~ # echo 3 > /proc/sys/net/ipv6/conf/enp0s5/addr_gen_mode
>> tw:~ # echo 2 > /proc/sys/net/ipv6/conf/enp0s5/use_tempaddr
>> tw:~ # cat /proc/sys/net/ipv6/conf/enp0s5/use_tempaddr
>> 2
>> tw:~ # cat /proc/sys/net/ipv6/conf/enp0s5/addr_gen_mode
>> 3
>> tw:~ # ip l set dev enp0s5 name ififif
>> tw:~ # ip l set dev ififif up
>> tw:~ # cat /proc/sys/net/ipv6/conf/ififif/use_tempaddr
>> 2
>> tw:~ # cat /proc/sys/net/ipv6/conf/ififif/addr_gen_mode
>> 3
>>
> 
> Thanks for taking the time to demonstrate this. But it does not comapre,
> as you do not remane the interface.

May 23 09:05:52 tw.0.2.15 kernel: virtio_net virtio4 ififif: renamed
from enp0s5

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


Re: [systemd-devel] systemd-networkd, IPv6PrivacyExtensions=kernel, sysctl and devicenames

2020-05-23 Thread Andrei Borzenkov
22.05.2020 22:17, Ede Wolf пишет:
> Am 22.05.20 um 17:58 schrieb Andrei Borzenkov:
>>>
>>> The problem is, that sysctl.conf is being executed before the interfaces
>>> get their eventual names.
>>>
>>
>> That sounds like actual bug. What systemd version do you use?
> 
> At least it is, what the journal suggest, as seen below. However,
> generally it sounds like a good idea to read sysctl.conf as early as
> possible
> 
> 
> As for my version:
> 
> $  pacman -Qs systemd
> local/systemd 245.5-2
>     system and service manager
> local/systemd-libs 245.5-2
>     systemd client libraries
> local/systemd-sysvcompat 245.5-2
>     sysvinit compat for systemd
> 
> $ uname -a
> Linux willy 5.6.13-arch1-1 #1 SMP PREEMPT Thu, 14 May 2020 06:52:53
> + x86_64 GNU/Linux
> 
> Same issues with the arch lts-kernel, this behaviour is consistent and
> easily reproducable.
> 
> 
>>>>> And the logs read:
>>>>>
>>>>> journalctl -b0 | grep -E 'sysctl|ens3|eth0'
>>>>> 08:56:46 systemd[263]: systemd-sysctl.service: Executing:
>>>>> /usr/lib/systemd/systemd-sysctl
>>>>> 08:56:46 systemd-sysctl[263]: Couldn't write '2' to
>>>>> 'net/ipv6/conf/ens3/addr_gen_mode', ignoring: No such file or
>>>>> directory
>>>>> 08:56:46 systemd-sysctl[263]: Couldn't write '2' to
>>>>> 'net/ipv6/conf/ens3/use_tempaddr', ignoring: No such file or directory

Sorry, I did not pay attention. Errors come from systemd-syctl service
which indeed runs concurrently with udev and races with interface
renaming. But udev also applies settings individually to each interface,
see below.

>>>>> 08:56:47 kernel: virtio_net virtio0 ens3: renamed from eth0
>>>>> 08:56:47 systemd[1]: sys-subsystem-net-devices-ens3.device: Changed
>>>>> dead
>>>>> -> plugged
>>>>> 08:56:47 systemd[1]:
>>>>> sys-devices-pci:00-:00:03.0-virtio0-net-ens3.device: Changed
>>>>> dead -> plugged
>>>>> 08:56:51 systemd-networkd[459]: ens3: Interface name change detected,
>>>>> ens3 has been renamed to eth0.
>>
>> I wonder where this comes from.
>>
>>>>> 08:56:51 systemd-networkd[459]: eth0: Interface name change detected,
>>>>> eth0 has been renamed to ens3.
>>>>> 08:56:51 systemd-networkd[459]: ens3: IPv6 successfully enabled
>>>>> 08:56:51 systemd-networkd[459]: ens3: Link UP
>>>>> 08:56:51 systemd-networkd[459]: ens3: Gained carrier
>>>>> ...
> 
> Same wonders here, but, despite the mysterial double renaming,
> systemd-sysctl is still being called before even the first rename. A
> good second here. So I have no chance to set any values for ens3 at all.
> 

Given lack of errors after interface rename, settings were most probably
applied correctly.

> 
>>
>> udev applies sysctl just once - when interface first appears. 
> 
> Any deeper insight on this? I was under the impression, sysctl is read
> by systemd-sysctl only and not by udev at all? But admittedly, I am not
> very knowledgable here. So I'd like to improve.
> 

udev invokes systemd-sysctl for specific interface as part of event
processing, normally in 99-systemd.rules but of course could be
anywhere. Just search for systemd-sysctl in rules files.

> 
>> using final name (that can be different from initial kernel name). So if
>> device appeared under eth0 and got name ens3 during event procesing,
>> udev applies sysctl to ens3 and never to eth0. If udev applied settings
>> to eth0 before rename, these settings would be preserved after rename.
> 
> That does at least not correspond to my observation.
> 
> It seems, the kernel creates
> 
> net/ipv6/conf/eth0/use_tempaddr
> 
> upon detection and after renaming,
> 
> net/ipv6/conf/ens3/use_tempaddr
> 
> does not keep the values.
> 

tw:~ # systemctl stop NetworkManager.service
tw:~ # ip l set dev enp0s5 down
tw:~ # cat /proc/sys/net/ipv6/conf/enp0s5/use_tempaddr
1
tw:~ # cat /proc/sys/net/ipv6/conf/enp0s5/addr_gen_mode
1
tw:~ # echo 3 > /proc/sys/net/ipv6/conf/enp0s5/addr_gen_mode
tw:~ # echo 2 > /proc/sys/net/ipv6/conf/enp0s5/use_tempaddr
tw:~ # cat /proc/sys/net/ipv6/conf/enp0s5/use_tempaddr
2
tw:~ # cat /proc/sys/net/ipv6/conf/enp0s5/addr_gen_mode
3
tw:~ # ip l set dev enp0s5 name ififif
tw:~ # ip l set dev ififif up
tw:~ # cat /proc/sys/net/ipv6/conf/ififif/use_tempaddr
2
tw:~ # cat /proc/sys/net/ipv6/conf/ififif/addr_gen_mode
3


What likely happens in your case is something else changes settings
after they had been applied by udev. Notice I had

Re: [systemd-devel] systemd-networkd, IPv6PrivacyExtensions=kernel, sysctl and devicenames

2020-05-22 Thread Andrei Borzenkov
22.05.2020 15:44, Ede Wolf пишет:
> Hello,
> 
> Thanks for replying. As I have written, I am using no custom .rules or
> .link file. /etc/udev/rules.d is empty and /etc/systemd/network only
> contains .network files.
> 

This is irrelevant. *ANY* rule can set device name which will rename
interface. It does not matter whether these rules are in /usr/lib or
/etc. Where do you think those "predictable" names come from? Kernel
starts always with ethX.

> But I believe the problem would not change. As wether I rename an
> interface or 99-default.link as part of systemd-networkd does it, should
> make no difference.
> 
> The problem is, that sysctl.conf is being executed before the interfaces
> get their eventual names.
> 

That sounds like actual bug. What systemd version do you use?

> What would work is disabling interface renaming alltogether by adding
> net.ifnames=0 to the kernel, but those ethx names are not reliably
> persistent. So nothing is really won here. Unless you only have one
> interface, that is.
> 
> Unless I have missed somthing, that's why I am asking, those settings
> would need to be moved  from sysctl.conf to the [Network] section of a
> corresponding unit file alltogether, so that systemd has control over it.
> 
> As a workaround I have set default values:
> 
> net.ipv6.conf.default.stable_secret=
> net.ipv6.conf.default.addr_gen_mode=2
> net.ipv6.conf.all.addr_gen_mode=2
> 
> 
> But I am getting different results on two different machines. One, where
> it works even on a systemd renamed link, and one, where it is not. Still
> trying to figure out, why that is.
> 
> But the key should be to be able to set those on a per link base, what I
> have not been able to do so far at all.
> 
> 
> 
> 
> Am 22.05.20 um 12:21 schrieb Kevin P. Fleming:
>> Do you have a udev 'persistent network device name' rules file in
>> /etc/udev/rules.d? Many distributions install such a rules file by
>> default, and this renames the interfaces to 'standard' names.
>>
>> On Fri, May 22, 2020 at 3:47 AM Ede Wolf  wrote:
>>>
>>> Hello,
>>>
>>> I am trying to enable temporary and/or stable addresses for a link and
>>> am most likely running into troubles with the device naming. However, I
>>> do not change any network name myself, neither in udev nor as part or a
>>> link file, it's just the standard system settings (from Arch, in case
>>> that matters).
>>>
>>> my sysctl.conf (both ens3 and eth0 refer to the same interface):
>>>
>>>
>>> net.ipv6.conf.ens3.addr_gen_mode = 2
>>> net.ipv6.conf.ens3.use_tempaddr = 2
>>>
>>> net.ipv6.conf.eth0.addr_gen_mode = 2
>>> net.ipv6.conf.eth0.use_tempaddr = 2
>>>
>>>
>>> And the logs read:
>>>
>>> journalctl -b0 | grep -E 'sysctl|ens3|eth0'
>>> 08:56:46 systemd[263]: systemd-sysctl.service: Executing:
>>> /usr/lib/systemd/systemd-sysctl
>>> 08:56:46 systemd-sysctl[263]: Couldn't write '2' to
>>> 'net/ipv6/conf/ens3/addr_gen_mode', ignoring: No such file or directory
>>> 08:56:46 systemd-sysctl[263]: Couldn't write '2' to
>>> 'net/ipv6/conf/ens3/use_tempaddr', ignoring: No such file or directory
>>> 08:56:47 kernel: virtio_net virtio0 ens3: renamed from eth0
>>> 08:56:47 systemd[1]: sys-subsystem-net-devices-ens3.device: Changed dead
>>> -> plugged
>>> 08:56:47 systemd[1]:
>>> sys-devices-pci:00-:00:03.0-virtio0-net-ens3.device: Changed
>>> dead -> plugged
>>> 08:56:51 systemd-networkd[459]: ens3: Interface name change detected,
>>> ens3 has been renamed to eth0.

I wonder where this comes from.

>>> 08:56:51 systemd-networkd[459]: eth0: Interface name change detected,
>>> eth0 has been renamed to ens3.
>>> 08:56:51 systemd-networkd[459]: ens3: IPv6 successfully enabled
>>> 08:56:51 systemd-networkd[459]: ens3: Link UP
>>> 08:56:51 systemd-networkd[459]: ens3: Gained carrier
>>> ...
>>>
>>>
>>> As it appears to me, the eth0 settings from sysctl.conf have been
>>> accepted - at least no errors are logged in this regard -, but are lost,
>>> because the interface got renamed afterwards. The ens3 interface was not
>>> yet known at time of invoking systemd-sysctl, and therefore we get the
>>> errors. That in turn means, the settings are not being applied.
>>>

udev applies sysctl just once - when interface first appears. It is
using final name (that can be different from initial kernel name). So if
device appeared under eth0 and got name ens3 during event procesing,
udev applies sysctl to ens3 and never to eth0. If udev applied settings
to eth0 before rename, these settings would be preserved after rename.

>>> To make things worse, in sysctl.conf I've additionally set:
>>>
>>> net.ipv6.conf.default.stable_secret=
>>> net.ipv6.conf.default.addr_gen_mode=2
>>> net.ipv6.conf.all.addr_gen_mode=2
>>>
>>>
>>> Which results in all IP address having a stable privacy scope link,
>>> _execpt_ of course ens3. The one that would be by far most important.
>>>
>>> What am I missing here? And insight is highly appreciated
>>>
>>> Thanks
>>>
>>> Ede
>>> 

Re: [systemd-devel] systemd update "forgets" ordering for shutdown

2020-05-17 Thread Andrei Borzenkov
17.05.2020 03:32, Michael Chapman пишет:
> On Fri, 15 May 2020, Frank Steiner wrote:
>> Hi,
>>
>> I need to run a script on shutdown before any other service is stopped.
>> Due to an advice Lennart gave a while ago I'm using this service file
>> (with multi-user.target being our default runlevel target):
>>
>> [Unit]
>> After=multi-user.target
>>
>> [Service]
>> Type=oneshot
>> ExecStart=/bin/true
>> ExecStop=/usr/lib/systemd/scripts/halt.local.bio
>> TimeoutSec=120
>> RemainAfterExit=yes
> 
> This seems inherently fragile.
> 
> If `multi-user.target` were to be stopped for whatever reason (and this 
> is generally possible), the ordering dependencies between services 
> Before=multi-user.target and services After=multi-user.target are broken. 

This is universally true. Do you have suggestion how it can be done
differently?

Even if multi-user.target is manually stopped, there is no way normal
service can be stopped concurrently with local filesystems, simply
because normal service is always ordered After=basic.target. Unless of
course we manually stop basic.target and sysinit.target as well :)

I cannot reproduce it using trivial service definition on openSUSE Leap
15.1 which should have the same systemd as SLE 15 SP1. So possibilities are

1. Something in unit definition triggers some bug in systemd. In this
case exact full unit definition is needed. Also shutdown log with debug
log level will certainly be useful.

2. ExecStop command is not synchronous, it forks and continues in
background. In this case probably systemd assumes unit is stopped and
continues. Again, log with debug log level would confirm it.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd update "forgets" ordering for shutdown

2020-05-16 Thread Andrei Borzenkov
16.05.2020 19:28, Frank Steiner пишет:
> Hi Andrei,
> 
> Andrei Borzenkov wrote:
>  
>> Can you reproduce it by simply running "systemctl daemon-reexec" without
>> any package update? 
> 
> Yes, indeed! This is enough to destroy the ordering for the next
> shutdown.
> 

Do

systemctl show your-unit.service

before and after daemon-reexec. Is there any difference?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Ordering a service before remote-fs-pre.target makes it quite longer

2020-05-16 Thread Andrei Borzenkov
15.05.2020 12:57, Thomas HUMMEL пишет:
> 
> In other words : is it a bad practice to order a home made service
> before remote-fs-pre.target ?
> 

Why would it be? The very reason remote-fs-pre.target was added is to
allow services to be reliably started before remote mounts.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd update "forgets" ordering for shutdown

2020-05-16 Thread Andrei Borzenkov
15.05.2020 11:08, Frank Steiner пишет:
> Hi,
> 
> I need to run a script on shutdown before any other service is stopped.
> Due to an advice Lennart gave a while ago I'm using this service file
> (with multi-user.target being our default runlevel target):
> 
> [Unit]
> After=multi-user.target
> 
> [Service]
> Type=oneshot
> ExecStart=/bin/true
> ExecStop=/usr/lib/systemd/scripts/halt.local.bio
> TimeoutSec=120
> RemainAfterExit=yes
> 
> This works fine and the script indeed runs before anything else goes down.
> But: not always! But somtimes it happens that the ordering is forgotten
> and this script is stopped together with and/or after many others.
> Sometimes the halt.local.bio script is still running even after
> remote and local fs are going down.
> 
> By chance I was able to figure out that updating the systemd.rpm
> causes this problems. It is reproducible by reinstalling the
> currently installed systemd with "rpm -Uhv --force ...".
> I can reboot the host 5 times in a row with the script working
> fine, then I reinstall systemd and reboot => ordering fails.
> Calling "systemctl daemon-reload" right before reboot doesn't help.
> 

Can you reproduce it by simply running "systemctl daemon-reexec" without
any package update? If it works, try "systemctl daemon-reexec" followed
by "systemctl daemon-reload". This will simplify reproducing of this issue.

> systemd is 234-24.49.2, that's the version currently provided for
> SuSE Linux Enterprise 15 SP1.
> 
> Is this a known bug maybe fixed in some later version so that I
> could ask SuSE to add the patch?
> 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Ordering a service before remote-fs-pre.target makes it quite longer

2020-05-13 Thread Andrei Borzenkov
13.05.2020 21:57, Thomas HUMMEL пишет:
> Hello,
> 
> I'm using the xCAT (xcat.org) software to provision stateless HPC Centos
> 8.1 nodes. Via a systemd service called xcatpostinit1.service, it
> enables, at boot time, to run so called postscripts for, for instance
> 
> - configure eth nic with a manual (vs dhcp) NetworkManager profile
> - configure Infiniband nic
> - sync files from the xcat server.
> 
> I'm using it exactly for the 3 above examples. File syncing is quite
> light as it consists in syncing pre-created ssh hostkeys.
> 
> By default this service has got the following ordering dependency:
> 
> After=network.target rsyslog.service
> 

It does not match your graphs. Your service is apparently ordered after
network-online.target (not after network.target) and startup is most
certainly initiated before rsyslog.service. Not hat it explains anything
but at least you need to provide accurate facts when you ask question.

> and doesn't pull any dependency
> 
> For my own need, I added the following:
> 
> Before=beegfs-client.service
> Before=beegfs-helperd.service
> After=sshd-keygen.target
> 
> This works fine.
> 
> As one of the postscript this service runs adds a NetworkManager profile
> (to autoconnect from a dhcp-originating boot profile to a manual (same
> ip address) one, and since I nfs mount some filesystems I tought I
> should order units so as to setup network first and only then mount
> remote filesystems
> 
> I thus did add:
> 
> Before=remote-fs-pre.target
> 
> This has a funny result : it ultimately works but this
> xcatpostinit1.service then takes 1min+ to end vs 20sec when the latter
> dependency is not stated.
> 
> Please find here to systemd-analyze plot svg's reflecting the with
> Before=remote-fs-pre.target (boot-dep.svg) and without it (boot-nodep.svg)
> 
> http://dl.pasteur.fr/fop/GCPbmpii/boot-dep.svg
> 
> http://dl.pasteur.fr/fop/AcfI7CSh/boot-nodep.svg
> 
> I did spend a lot of time trying to figure out why such a difference,
> all things being equal otherwise.
> 
> The part of the service which takes time is the syncing of files which
> 
> - occurs before the network reconfiguring
> - consists in rsync'ing files from server to node
> - triggered by a REST API call (http/80) for what I saw in sources
> 
> I did not see any cycles nor anything that caught my eye turning systemd
> in debug mode neither.
> 
> As remote-fs-pre.target is a special target I thought I may did misuse
> it for that matter.
> 
> Can you help me figure out why the difference ?
> 


If startup of your service was initiated (as opposed to delaying
startup) it is really outside of systemd scope. Systemd has no control
over what your service does once ExecStart is spawned. You need to debug
your service to find out what happens.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] EXT :Antw: [EXT] Udev Regex

2020-05-06 Thread Andrei Borzenkov
On Wed, May 6, 2020 at 4:43 PM Lennart Poettering
 wrote:
>
> On Mi, 06.05.20 13:03, Boyce, Kevin P [US] (AS) (kevin.bo...@ngc.com) wrote:
>
> > Ulrich,
> >
> > I just noticed that too.  This seems rather restrictive given that one 
> > could have a system with many drives, and with GPT it is not unreasonable 
> > to have a large number of partitions as well.
> >
> > There should be a way in udev to write rules that can distinguish between 
> > /dev/sda and /dev/sdzfe87.  Matching with sd[a-z]* or even sd* does not 
> > provide enough granularity.
> >
> > What would it take to get this sort of request in to systemd-udev to
> > support perl style regular expressions that can group terms and
> > match multiple instances of a group with '+'?
>
> I am sorry, but no. We are talking about device nodes, i.e. file
> objects in the file system tree. It's generally understood that files
> are matched with globs, not regexes.
>
> There are things where regexes might be fine, but not matching of file
> names.
>
> Or to say this differently: as soon as you convinced bash to replace
> its glob matching with regex matching we can consider this for udev
> too.
>


bash already does it if extglob is set.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Udev Regex

2020-05-06 Thread Andrei Borzenkov
On Wed, May 6, 2020 at 3:23 PM Boyce, Kevin P [US] (AS)
 wrote:
>
> Good Morning List,
>
>
>
> Does anyone know how complicated of a regular expression can be utilized in a 
> udev rule?
>

I would ask udev manual page :)

>
>
> For instance I have a system with a lot of drives (sda through z aren’t 
> enough) and I want to write a rule that will match the physical block devices 
> for one rule and then a separate rule for partitions.
>
>
>
> Something like this, however the rules don’t seem to fire except when I 
> remove the ‘+’ from the rules:
>
> ACTION==”add”, SUBSYSTEM==”block”, KERNEL==”sd[a-z]+”, 
> SYMLINK+=”some_device_%k”
>
> ACTION==”add”, SUBSYSTEM==”block”, KERNEL==”sd[a-z]+[0-9]+”, 
> SYMLINK+=”some_device_%k”
>
>
>
> I am running systemd version 219-67.
>
>
>
> Kind Regards,
>
> Kevin
>
> ___
> 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] local-fs and remote-fs targets / passive active units

2020-05-05 Thread Andrei Borzenkov
05.05.2020 18:15, Thomas HUMMEL пишет:
> On 4/28/20 5:36 PM, Thomas HUMMEL wrote:
> 
>> 3) regarding local-fs dans remote-fs targets : I'm not really sure if
>> any fits in either passive or active units.
> 
> Hello again,
> 
> regarding local-fs.target : is it legit for a custom service unit to
> pull it in with a Before=local-fs.target (no Wants or Requires) ?
> 

a) Before= does not pull anything anywhere.
b) as you already found, by default every service is ordered after
local-fs.target. You need DefalutDependencies=no if you want to start
your service that early.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] why is systemd-remount-fs.service needed in stage-2?

2020-05-04 Thread Andrei Borzenkov
04.05.2020 00:03, Arian Van Putten пишет:

> 
> My gut feeling the answer to this question is "not all initrd's use
> systemd; so they might not parse /sysroot/etc/fstab so early we need to
> account for that". Is that the case?
> 

It is more "not every system uses initrd".
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] How does KillSignal interact with TimeoutStopSec in systemd?

2020-04-28 Thread Andrei Borzenkov

27.04.2020 08:43, Debraj Manna пишет:

Can someone let me know the following about systemd service shutdown
sequence

1.

If I have specified KillSignal=SIGTERM then how does this interact this
TimeoutStopSec ? Does this mean that during shutdown of service, first
SIGTERM will be sent and if the service is still running after
TimeoutStopSec SIGKILL will be sent (if SendSIGKILL is set to yes? I am
asking about the case where nothing is specified in ExecStop.


Yes, that's correct


2.

Does TimeoutStopSec take into account ExecStop and all ExecPostStop?



TimeoutStopSec is for every command. If ExecStopPost command fails (or 
times out) subsequent commands are not executed, but if each command 
requires almost TimeoutStopSec time, total execution time will be close 
to ExecStopPost commands multiplied by TimeoutStopSec.

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


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

2020-04-25 Thread Andrei Borzenkov
24.04.2020 16:57, John пишет:
> I'd like to have systemd (user mode) call a bash script with different
> tokens under two conditions:
> 1) When the user starts/stops a service (token would be either "sync"
> or "unsync")
> 2) When a timer tells it to run (token would be "sync")
> 
> Thus far, I have been accomplishing these with 1 service and 1
> service/timer combo:
> 
> All three files can be found here for reference:
> https://github.com/graysky2/profile-sync-daemon/tree/ce290b54069b015879f53d631f82ed97bfe73d47/init
> 
> So the user starts psd.service and both psd-resync.{service,timer} get
> activated and run as expected.  The problem is when the script that
> psd.service calls ends in an error state...

ps.service does not call any script on startup.

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

Assuming service that fails is psd-resync.service, as far as I can tell
the only way is to add BindsTo=psd-resync.service to both psd.service
and psd-resync.timer.

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

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


Re: [systemd-devel] networkd: IPv6 prefix delegation not updated when prefix changes

2020-04-13 Thread Andrei Borzenkov
13.04.2020 18:18, Tobias Brink пишет:
> Hello systemd devs and users,
> 
> my internet connection is established by a router provided by my ISP (a
> Fritz Box to be precise). It can hand out delegated IPv6 prefixes via
> DHCPv6. I use a Linux box in between this router and my internal network
> to provide additional firewalling, OpenVPN, etc. For this, I request an
> IPv6 prefix for the internal network using networkd. This works. But the
> provider (like most non-business offerings) resets the public IPv4
> address and IPv6 prefix from time to time. The prefix delegation on my
> Linux box is not updated at this point and the old delegated prefix
> expires. Only "networkctl reconfigure" on the external interface leads
> to a new prefix delegation being obtained. Routes for the old prefixes,
> though, remain indefinitely, potentially causing trouble.
> 
> I do believe this to be a problem with networkd, but I'm new to IPv6 and
> wanted to ask here first if there's a problem with my configuration or
> if the ISP-provided router is maybe buggy instead. If I should instead
> open an issue on GitHub or if more information is needed, please tell
> me.
> 

DHCPv6 IA prefix option includes lifetime. Client is expected to renew
delegation before lifetime expires. If information handed out to client
expires before this timer, standard defines Reconfigure message that can
be used by server to inform client that it needs to renew lease. In both
cases it is really up to provider and its equipment.

Still even if all of this is implemented there is still some short
period of lost connectivity, before client has renewed delegation and
pushed updated information downstream. To make it completely transparent
provider would need to keep both prefixes as valid for some transitional
time.

Do you have packet trace at the time prefix is changed? If CPE sends
Reconfigure message, then it is networkd fault by not acting on it.
Otherwise I do not think anything ca be done on this level.


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


Re: [systemd-devel] networkd: IPv6 prefix delegation not updated when prefix changes

2020-04-13 Thread Andrei Borzenkov
13.04.2020 20:04, Andrei Borzenkov пишет:
> 
> Huh? You seem to misunderstand configuration. End host networkd knows
> nothing about prefix delegation, it gets its configuration from CPE router.
> 

Oops, ignore this. Sorry, my fault.


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


Re: [systemd-devel] networkd: IPv6 prefix delegation not updated when prefix changes

2020-04-13 Thread Andrei Borzenkov
13.04.2020 18:26, Kevin P. Fleming пишет:
> This is a bit tricky, since RAs and prefix delegation are not really
> related. What you have described is proper behavior on the 'upstream'
> link side; when networkd sees the RA with the new prefix, and the
> lifetime of the old prefix set to zero, it properly adjusts that link
> to use the new prefix.
> 
> What it can't do is trigger a new prefix delegation request as a
> result, because they are not really related. Commonly, the link used
> between the router which asks for the delegation and the router which
> provides it uses a prefix which is totally unrelated to the delegated
> prefix, and so changes to the prefix on that inter-router link don't
> affect the delegation at all.
> 

Huh? You seem to misunderstand configuration. End host networkd knows
nothing about prefix delegation, it gets its configuration from CPE router.

> What you're experiencing here is a delegation which has expired
> earlier than the DHCPv6 server claimed that it would expire, which is
> really unfriendly.
> 
> On Mon, Apr 13, 2020 at 11:18 AM Tobias Brink  wrote:
>>
>> Hello systemd devs and users,
>>
>> my internet connection is established by a router provided by my ISP (a
>> Fritz Box to be precise). It can hand out delegated IPv6 prefixes via
>> DHCPv6. I use a Linux box in between this router and my internal network
>> to provide additional firewalling, OpenVPN, etc. For this, I request an
>> IPv6 prefix for the internal network using networkd. This works. But the
>> provider (like most non-business offerings) resets the public IPv4
>> address and IPv6 prefix from time to time. The prefix delegation on my
>> Linux box is not updated at this point and the old delegated prefix
>> expires. Only "networkctl reconfigure" on the external interface leads
>> to a new prefix delegation being obtained. Routes for the old prefixes,
>> though, remain indefinitely, potentially causing trouble.
>>
>> I do believe this to be a problem with networkd, but I'm new to IPv6 and
>> wanted to ask here first if there's a problem with my configuration or
>> if the ISP-provided router is maybe buggy instead. If I should instead
>> open an issue on GitHub or if more information is needed, please tell
>> me.
>>
>> All details below:
>>
>> Setup
>> =
>>
>> I use the current Debian stable (buster) with systemd from backports
>> (systemd --version: "systemd 244 (244.3-1~bpo10+1)"). I also quickly
>> tried compiling and running networkd from git master, but the issue
>> seems to remain unfixed.
>>
>> Configuration:
>>
>> #/etc/systemd/network/10-enp3s0.network <- the "external" interface
>>
>> [Match]
>> Name=enp3s0
>>
>> [Network]
>> Address=
>> Gateway=
>> Address=fdxx:::::1/64
>> IPv6AcceptRA=yes
>> DHCP=ipv6
>> IPv6PrivacyExtensions=true
>>
>> [DHCPv6]
>> # Note: usually, the ISP router is configured to only set the "Other
>> # Configuration" flag. I also tried changing it to set the "Managed"
>> # flag in router advertisements, but with the setting below, there
>> # is no difference in the behavior of networkd.
>> ForceDHCPv6PDOtherInformation=yes
>>
>>
>> #/etc/systemd/network/20-br0.network <- the "internal" interface
>>
>> [Match]
>> Name=br0
>>
>> [Network]
>> Address=
>> Address=fdxx:::::1/64
>> IPv6PrefixDelegation=yes
>>
>> [IPv6PrefixDelegation]
>> Managed=yes
>> OtherInformation=yes
>> RouterLifetimeSec=7200
>> EmitDNS=yes
>> DNS=fdxx:::::1
>> DNSLifetimeSec=7200
>>
>> [IPv6Prefix]
>> Prefix=fdxx:::::/64
>> ValidLifetimeSec=7200
>> PreferredLifetimeSec=3600
>>
>>
>> The issue
>> =
>>
>> This is an example observed with the help of tcpdump and log files. I
>> still have this data if more details are needed.
>>
>> For the sake of the example, let's say the public IPv6 prefix was
>> 2001:1:0:0::/56 before resetting the internet connection and
>> 2001:2:0:0::/56 after.
>>
>> 0) enps0 has a prefix of 2001:1:0:0::/64 (obtained via router
>>advertisement); br0 a prefix 2001:1:0:1::/64 (obtained via DHCPv6
>>prefix delegation).
>>
>> 1) Internet connection is reset. The ISP-provided router sends a router
>>advertisement with a new IPv6 prefix 2001:2:0:0::/64 with a preferred
>>lifetime of 3600 and the old prefix 2001:1:0:0::/64 with a preferred
>>lifetime of 0. The "Other Configuration" flag is set.
>>
>> 2) networkd updates enp3s0 with this prefix. No DHCPv6 traffic is
>>triggered. The configuration of br0 remains unchanged. The old prefix
>>is no longer accepted by the ISP and IPv6 connectivity is lost for
>>the internal network.
>>
>> 3) A while later, the ISP-provided router sends a new router
>>advertisement, this time only containing the new IPv6 prefix
>>2001:2:0:0::/64. This triggers no changes in networkd.
>>
>> 4) Still a bit later, networkd wants to renew the 2001:1:0:1::/64 prefix
>>of br0 and sends a DHCPv6 Renew. The ISP-provided router responds
>>with "NoBindig", status message 

Re: [systemd-devel] netdev templates and location of network units

2020-03-23 Thread Andrei Borzenkov
23.03.2020 14:15, Kevin P. Fleming пишет:
> Input files for systemd-networkd are not systemd unit files, so
> there's a good chance that the rules for finding and processing them
> are much simpler. That would explain why template/instance files don't
> work.
> 
> The manpage for systemd.network does indicate that files will be
> loaded from /usr/local/lib/systemd/network though, so if they aren't
> being picked up that's odd.
> 

This is relatively recent change since v242.

> https://www.freedesktop.org/software/systemd/man/systemd.network.html
> 
> On Mon, Mar 23, 2020 at 6:51 AM Christian Schneider
>  wrote:
>>
>> Hi all,
>> for an embedded device with Linux and systemd boot, we wanted to deploy
>> custom network and netdev units.
>> We tried placing them in /usr/local/lib/systemd/network, next to service
>> files for custom services in /usr/local/lib/systemd/system. The network
>> units aren't picked up by systemd, the custom service files are, though.
>> Since this was a bit surprising, I want to ask, what is the rationale
>> behind this, and what would be the recommended location of the
>> network/netdev files? Right now we placed them in /etc/systemd/network
>>
>> Furthermore, since we make heavy use of vlan, I tried to create a
>> template netdev file where the instance goes in as vlan id, but when I
>> tried to reference instance of the template in the network file, I got
>> syntax errors. Is there a rational behind this or is it just not
>> implemented to be use templates for netdev?
>>
>> BR, Christian
>>
>> ___
>> 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 mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Ordering after udev applied rules to `/dev/dri/card0`

2020-03-19 Thread Andrei Borzenkov
19.03.2020 19:47, Paul Menzel пишет:
> Dear systemd folks,
> 
> 
> I am using Debian Sid/unstable with systemd 245.2 and Weston 8.0.0.
> 
> I amtrying to start a graphical desktop as soon as possible. Currently,
> I use Weston, but unfortunately accessing `/dev/dri/card0` it gets a
> permission denied error. The Weston service unit is ordered after
> `systemd-logind.service`.
> 
> Weston now fails to start, because it gets a permission denied error
> accessing `/dev/dri/card0` [1][2].
> 
>     drmModeSetCrtc(backend->drm.fd, output->crtc_id,
> scanout_state->fb->fb_id, 0, 0, connectors, n_conn, >mode_info);
> 
> Right before Weston starts, the permission and ownership are like below.
> 
>     $ ls -l /dev/dri:
>     insgesamt 0
>     crw--- 1 root root 226,   0 Mär 19 17:29 card0
>     crw--- 1 root root 226, 128 Mär 19 17:29 renderD128
> 
> After udev applied the rules, it looks like below, meaning users in
> group `video` are allowed to access the device.
> 
>     $ ls -l /dev/dri
>     insgesamt 0
>     drwxr-xr-x  2 root root 80 Mär 19 17:29 by-path
>     crw-rw+ 1 root video  226,   0 Mär 19 17:29 card0
>     crw-rw+ 1 root render 226, 128 Mär 19 17:29 renderD128
> 
> Is there a way to order a service in such a way, that it’s guaranteed
> that udev rules to devices were applied?
> 

After=device should work. udev announces device after all rules have
been processed.

> A small script applying permissions and ownership manually in
> `ExecStartPre=` seems to work around the (graphics) issue.
> 
> If it cannot be solved with ordering, what would you suggest?
> 
> [1]: https://gitlab.freedesktop.org/wayland/weston/issues/382
> [2]:
> https://gitlab.freedesktop.org/wayland/weston/-/blob/master/libweston/backend-drm/kms.c#L741
> 
> ___
> 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] _netdev for system root mount?

2020-03-13 Thread Andrei Borzenkov
13.03.2020 11:19, Mantas Mikulėnas пишет:
> On Fri, Mar 13, 2020 at 10:03 AM Thomas Blume  wrote:
> 
>> Hi,
>>
>> I have a SUSE SLES system where system root is provided via iscsi firmware
>> (ibft).
>> The installer automatically adds the _netdev parameter to the system root
>> mount.
>> The ordering when applying the _netdev parameter is documented as:
>>
>> -->
>> Network mount units are ordered between remote-fs-pre.target and
>> remote-fs.target, instead of local-fs-pre.target and local-fs.target. They
>> also
>> pull in network-online.target and are ordered after it and network.target.
>> --<
>>
>> On system start, I can see this:
>>
>> -->
>> Mär 12 16:38:11 install systemd[1]:
>> dev-disk-by\x2duuid-b51ee00b\x2d2a1f\x2d48f9\x2da024\x2dc4107d68b7b8.device:
>> Dependency Before=network-online.target ignored (.device units cannot be
>> del>
>> Mär 12 16:38:11 install systemd[1]:
>> dev-disk-by\x2duuid-b51ee00b\x2d2a1f\x2d48f9\x2da024\x2dc4107d68b7b8.device:
>> Dependency Before=network.target ignored (.device units cannot be delayed)
>> Mär 12 16:38:11 install systemd[1]:
>> dev-disk-by\x2duuid-515E\x2d433F.device: Dependency
>> Before=network-online.target ignored (.device units cannot be delayed)
>> Mär 12 16:38:11 install systemd[1]:
>> dev-disk-by\x2duuid-515E\x2d433F.device: Dependency Before=network.target
>> ignored (.device units cannot be delayed)
>> --<
>>
>> Which looks like _netdev becomes almost a noop.
>> The only effect I can see afterwards is that the system root mount gets
>> ordered
>> below remote-fs.target:
>>
>>
> Somehow the 'cannot be delayed' message does not make sense with Before=.
> 
> But it feels like the dependency itself is backwards, too, it should be
> *After=* network.target... At least I see the regular
> systemd-fstab-generator adds After=, which makes more sense, but it still
> triggers the same message.
> 

This is just confusing message, current systemd should print
After=network.target here (see commit
c80a9a33d04fb4381327a69ce929c94a9f1d0e6c).

> I guess there's a bug in there somewhere but I'm not sure where.
> 
> 
>>
>> ● └─remote-fs.target
>> ●   ├─-.mount
>> ●   ├─boot-efi.mount
>> ●   └─iscsi.service
>>
>> But this is also a noop, because system root is already mounted in the
>> initrd
>> and has no more relevance after switch root.
>> It could be even dangerous, because on shutdown the system root mount
>> might be
>> attempted to stop before the system is switching back to the initrd.
>>
> 
> AFAIK the root mount is never stopped (and has the 'perpetual' flag set). I
> don't think it would even be *possible* to do so because pid1 itself is
> being executed from there, as well as there's still other filesystems
> (/run, /dev) mounted on top of it. (Which is the entire point of switching
> back to the shutdown-initramfs.)
> 
> Either way – stopping a mount literally just unmounts the filesystem (which
> is supposed to be a safe operation). I'd probably be more worried about
> iscsi.service, since the blockdev losing connection *before* its fs is
> unmounted is actually the dangerous part...
> 

And what is the "official" way to prevent various units required by root
mount from being stopped during shutdown? There could be arbitrarily
deep stack (NIC - iSCSI - multipath - raid - lvm - crypto - ...).

And no, DefaultDepedencies=no is not an answer because it just shifts
the question to "how to add this directive to one instance only".
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Redirect logs from script to systemd's StandardOutput file

2020-03-13 Thread Andrei Borzenkov
12.03.2020 12:10, Ani A пишет:
> Hello,
> 
> I am on Ubuntu 18.04.2, and I have systemd version 237. I have some common 
> tasks
> which need to happen prestart and poststop which I have moved to a
> script. All unit
> files look like:
> 
> StandardOutput=file:/var/log/my-.log
> ExecStartPre=/path/to/helper.sh -t prestart -u 
> ExecStopPost=/path/to/helper.sh -t poststop -u 
> ExecStart=/path/to/my/exe
> 
> where  is the name of the systemd unit file.
> 
> I use systemd's directive to log stdout to file, and in the prestart
> and poststop actions also
> I try to write some logs to the same file with shell echo, like:
> 
> echo "..." >> /var/log/my-.log
> 

It is not clear where you are using this command. In one of scripts that
are part of unit definition? In some other script that is run outside of
running unit? In interactive shell session?

> The logs that is written by the script does not appear in the log file!
> Is there anything wrong here (missing something) ?
> 
> --
> Ani
> ___
> 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] Shutdown behavior follow up

2020-02-22 Thread Andrei Borzenkov
22.02.2020 22:50, jay.bur...@fujitsu.com пишет:
> All,
> 
> Referring to my last email regarding the systemd shutdown behavior.  I am 
> working on the assumption that the idea of honoring the first shutdown request
> is the preferred way to go. If not this email can be ignored.
> 
> I have reproduced the same behavior using a fedora 31 machine with systemd 
> v243. I have a proposed fix, including source file change, patch file and 
> sample service
> which can be used to both show the problem and show the fix. I am not sure if 
> this is the right forum to attach those files.

Create pull request on guthub:

https://github.com/systemd/systemd


> 
> If this is the desired behavior, I am wondering  what are my next steps to 
> get this into the next systemd delivery. I have not done this before so I am 
> looking for some instruction?
> 
> Thanks in advance,
> -Jay
> 
> -Original Message-
> From: Lennart Poettering  
> Sent: Monday, January 13, 2020 4:33 AM
> To: Burger, Jay 
> Cc: systemd-devel@lists.freedesktop.org; Dang, James 
> ; Berger, Daniel ; 
> Mahabaleshwar, Niranjan 
> Subject: Re: [systemd-devel] Shutdown behavior
> 
> On Fr, 10.01.20 10:56, Jay Burger (jay.bur...@us.fujitsu.com) wrote:
> 
>> I made the same type of change in the emergency_action() function in v232.
>>
>> Question 1: Would this be considered a problem with the design, 
>> needing an upstream fix? Or would this be considered a particular user 
>> issue, to be fixed with an isolated patch, like we have done? If the 
>> latter is the answer to this then would this be considered a legit fix 
>> for our purposes? Or is there a better way to handle this use case? I 
>> know fixing my user services to not fail on the shutdown would be 
>> preferable, but pulling teeth is not in my skillset.
> 
> Hmm, so what is the expected behaviour here? If one service requires a reboot 
> and another a poweroff, and one is triggered first and the other second, then 
> I can at least think of four policies that make
> sense:
> 
> 1. first requested always wins
> 
> 2. last requested always wins
> 
> 3. reboot is the positive outlook, and thus always wins
> 
> 4. poweorff is the positive outlook, and thus always wins.
> 
> Unless I am mistaken we currently implement policy 2. Which one would you 
> prefer? Can you make a good case why it would be better in the general case?
> 
> I have the suspicion we should just adopt the best possible policy here and 
> stick to it and not make things needlessly configurable. But it's a matter of 
> discussion which one that is...
> 
>> Question 2: I recently found a case where a poweroff shutdown was 
>> triggered while the system was in the "starting" state and a service 
>> failure occurred during the shutdown. In this case my logic change did 
>> not prevent the shutdown from changing to a reboot. This check of the 
>> manager_state found the state was still "starting" and the poweroff 
>> was again changed to a reboot. Is there a different logic path taken 
>> when in the starting state as opposed to the running state?
> 
> Not really, no.
> 
> 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] Dynamic .timer scheduling

2020-01-29 Thread Andrei Borzenkov
28.01.2020 21:46, Johannes Ernst пишет:
> Is there a best practice for scheduling .timers based on what happened in a 
> previous run?
> 
> Pseudocode:
> 
> while( true ) :
> delta = runService();
> sleep( delta );
> 
> I can think of …
> 
> 1) run the job frequently, but skip the bulk of its execution most of the 
> time (e.g. decrementing a counter saved somewhere)
> 2) have the job modify the .timer file at the end of each run (sounds … not 
> so great)
> 

I can only think of creating transient timer with systemd-run
--on-unit-inactive=delta.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] homed, LUKS2 passphrase encoding, and recovery key

2020-01-23 Thread Andrei Borzenkov
24.01.2020 06:56, Alexander E. Patrakov пишет:
>>
>> I assume users want their login passphrase to use local characters.
> 
> That's just an assumption, with no data presented to back it up.
> 

I have seen enough cases when users memorized Russian passwords and
entered ASCII characters based on keyboard layout mapping (they actually
mentally entered *Cyrillic* characters). I do not have any
scientifically relevant data though.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Antw: Re: confusing message "systemd[1]: nss-lookup.target: Dependency Before=nss-lookup.target dropped"

2020-01-18 Thread Andrei Borzenkov
15.01.2020 10:14, Ulrich Windl пишет:
>>>> Andrei Borzenkov  schrieb am 14.01.2020 um 20:08 in
> Nachricht :
>> 14.01.2020 10:57, Ulrich Windl пишет:
>>> Hi!
>>>
>>> I see the message
>>> systemd[1]: nss-lookup.target: Dependency Before=nss-lookup.target dropped
>>> several times, wondering:
>>>
>>> Does it say "nss-lookup.target" has a dependency "Before=nss-lookup.target"
> 
>> that was dropped, or is the first argument simply the wrong unit being 
>> displayed? It's systemd 228 of SLES 12 SP4.
>>>
>>
>> this is private SUSE patch so wrong list. But if you want to fix it -
> 
> Why is this the wrong list? I want to understand what's going on inside
> systemd.
> 

This message is result of downstream patch; generator that adds this
dependency is using private configuration file unrelated to systemd. So
nothing is going on inside systemd and unless you hit someone familiar
with SUSE code base you also won't get information on upstream list.

>> edit /etc/insserv.conf and delete +named from $named line. It is not
>> really the fix, more a workaround, but this entry was non-functional
>> anyway so it simply eliminates extra noise.
> 
> As the system in question does not have named installed, I wonder what's going
> on.
> 

https://github.com/openSUSE/systemd/blob/SLE12/src/insserv-generator/insserv-generator.c

> The man page systemd.special(7) explains: "systemd automatically adds
> dependencies of type
> After= for this target unit to all SysV init script service units with an LSB
> header referring to the "$named" facility."
> 
> So does that mean some LSB script in turn depends on nss-lookup.target?
> 
> How could I query "what depends on nss-lookup.target?" amd "what contributes
> to nss-lookup.target?"?
> 
>>
>>> It's hard to believe a unit has a Before= dependency on itself.
>>> Looking into the unit directly, I cannot see such a direct dependency.
>>> Or is it "Artificial intelligence biting in its own tail"?
>>>
>>> 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 
> 
> 
> 

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


Re: [systemd-devel] confusing message "systemd[1]: nss-lookup.target: Dependency Before=nss-lookup.target dropped"

2020-01-14 Thread Andrei Borzenkov
14.01.2020 10:57, Ulrich Windl пишет:
> Hi!
> 
> I see the message
> systemd[1]: nss-lookup.target: Dependency Before=nss-lookup.target dropped
> several times, wondering:
> 
> Does it say "nss-lookup.target" has a dependency "Before=nss-lookup.target" 
> that was dropped, or is the first argument simply the wrong unit being 
> displayed? It's systemd 228 of SLES 12 SP4.
> 

this is private SUSE patch so wrong list. But if you want to fix it -
edit /etc/insserv.conf and delete +named from $named line. It is not
really the fix, more a workaround, but this entry was non-functional
anyway so it simply eliminates extra noise.

> It's hard to believe a unit has a Before= dependency on itself.
> Looking into the unit directly, I cannot see such a direct dependency.
> Or is it "Artificial intelligence biting in its own tail"?
> 
> 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


Re: [systemd-devel] timed out waiting for device dev-disk-by\x2duuid

2020-01-11 Thread Andrei Borzenkov
04.01.2020 20:58, Georg Großmann пишет:
> Has this issue been fixed on either systemd or on BTRFS side in the
> meantime?

No. Each project says that from its side there is nothing to fix.

> I am currently testing a BTRFS raid1 with two disk in my
> virtualbox. I have installed a bootloader on both disks. After removing
> one of the disks I always get stuck at "timed out waiting for device
> dev-disk-by\x2duuid". Or is it still a 100% manual task to get the raid1
> up again?
> 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd kills user's scopes/sessions before shutdown service

2020-01-02 Thread Andrei Borzenkov
31.12.2019 08:34, Kamal Rathi пишет:
> Hi Git-Hub Mailing List,
> 
> I am designing a stop service which has to be run before the kill of user's
> scope / session .
> As the reboot or shutdown are being initiated the systemd kill all the
> users which are in user's.slice
> before the script ran so the script is of no use if the user session are
> killed first then the stop.service
> stop.service
> 
> [Unit]
> Description=Service to auto stop the EBS application
> DefaultDependencies=no
> Before=shutdown.target
> RefuseManualStart=true
> 
> [Service]
> Type=oneshot
> ExecStart=/startdb/stop/stop.sh
> 
> [Install]
> WantedBy=shutdown.target reboot.target
> 

This cannot work. systemd first stops everything then starts shutdown
target. Your unit is only pulled in at the moment shutdown target is
started.

> 
> https://github.com/systemd/systemd/issues/14318
> 

You have been told there how it should be done properly. What is the
point to start your question here with the same non-working variant?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Antw: Re: Why does initrd-parse-etc.service re-start initrd-fs.target?

2019-12-14 Thread Andrei Borzenkov
09.12.2019 10:06, Ulrich Windl пишет:
>>
>> After real root is mounted daemon-reload re-runs fstab generator which
>> parses real root /etc/fstab and may pull mount points from it.
> 
> I wonder: Are there realistic cases when the fstab in initrd is newer than the
> fstab in the root file system?

It has nothing to do with being "newer". It allows managing initrd
filesystems in one place and avoids need to re-create initrd every time
you need additional filesystem.

> That would be the case where detecting a "new"
> fstab would fail. I didn't dig into the generators, but an alternative method
> to detect a file change would be to compare the size as well (as cheap as
> stat()), or to compare some checksum (requires some more extra code). I feel
> the generators should fix the issue, not the user (i.e. restart).
> 
>> Restarting initrd-fs.target will propagate start request to its (newly
>> created) dependent mount units. Otherwise there is no obvious way to
>> start them (without explicitly starting each).
> 
> I never liked the idea of generators and /etc/fstab.
> 

It fits perfectly into systemd design goal - start services *on boot*
once. Most problems with systemd stem from attempt to use it as "dynamic
service manager" which it is not. This discussion is example of it.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Why does initrd-parse-etc.service re-start initrd-fs.target?

2019-12-14 Thread Andrei Borzenkov
09.12.2019 01:23, Colin Walters пишет:
> 
> 
> On Sun, Dec 8, 2019, at 5:20 PM, Colin Walters wrote:
>>
>>
>> On Fri, Dec 6, 2019, at 12:53 PM, Andrei Borzenkov wrote:
>>
>>> After real root is mounted daemon-reload re-runs fstab generator which
>>> parses real root /etc/fstab and may pull mount points from it.
>>> Restarting initrd-fs.target will propagate start request to its (newly
>>> created) dependent mount units. Otherwise there is no obvious way to
>>> start them (without explicitly starting each).
>>
>> Hmm, we mount things from /etc/fstab in the initramfs?  Why would we do 
>> that?  I thought they were mounted after the re-execution under the 
>> real root, as part of local-fs.target.
> 
> Ah, answering my own question, there's an x-initrd.mount fstab option.
> So then, the reason initrd-parse-etc.service does this is to mount any 
> x-initrd.mount fstab mounts?

That is how I understand it after looking in the source.

> If so, I'll do a patch to document this.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Why does initrd-parse-etc.service re-start initrd-fs.target?

2019-12-06 Thread Andrei Borzenkov
05.12.2019 17:31, Colin Walters пишет:
> See https://github.com/coreos/ignition-dracut/pull/140
> 
> Basically, we do a lot of nontrivial stuff in the initramfs (Ignition) and 
> this was re-starting some of our units, which I found surprising.
> 
> The behavior seems to have come from 
> https://github.com/systemd/systemd/commit/7d89ce303fb59743a4392eeb3110c00f100172ca

It was there much earlier, just that it restarted local-fs.target then.

> 
> Now, I understand the goal of having systemd re-load its configuration, but 
> why do we need to start the initrd-fs.target unit again?  Can't we assume 
> that the mount points set up for the root are still active?

After real root is mounted daemon-reload re-runs fstab generator which
parses real root /etc/fstab and may pull mount points from it.
Restarting initrd-fs.target will propagate start request to its (newly
created) dependent mount units. Otherwise there is no obvious way to
start them (without explicitly starting each).
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] No error even a Required= service does not exist

2019-11-29 Thread Andrei Borzenkov

25.11.2019 16:19, Mantas Mikulėnas пишет:

On Mon, Nov 25, 2019 at 3:13 PM Jörg Weinhardt  wrote:


Hi,

the behavior of systemd is not quite clear to me:
I have a service which requires another service to be started and running,
so I use a Requires= dependency to the required service.
But if the required service does not exist at all, there is no error
message from systemd.
e.g.

Requires=xyz.service

produces no complaint and starts the service even if there is no
xyz.service
Is this the normal behavior or can I configure systemd to throw an error
in this case?



The docs say you can get this behavior if you also have After=xyz.service.
(Not entirely sure why.)



Because systemd dependencies are about jobs, not about units. "B 
Requires A" does not mean "unit B should not be active without A being 
active". All that it means - "when submitting start job for B also 
submit start job for A and fail start job for B if start job for A 
failed previously". Without After both start jobs are submitted 
concurrently; there is nothing to check when B is being started (as 
start job for A is not complete at this point) so there is no reason to 
fail start job for B.


Which was the reason to invent BindTo in the first place - as poor man 
simulation of what everyone thinks Requires does (while it does not do it).

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

Re: [systemd-devel] Unload disabled units

2019-11-21 Thread Andrei Borzenkov
15.09.2019 6:12, Daniel Duong пишет:
> Hi,
> 
> I have a 2 template units: 1 for a service and 1 for a socket. Each
> instance is a version of my web application.
> 
> After a successful deploy, I stop and disable the old version and I
> enable the new one:
>   systemctl start belleshop@0.2.socket
>   # Test that everything is fine
>   systemctl enable belleshop@0.2.socket
>   systemctl stop belleshop@0.1.socket
>   systemctl stop belleshop@0.1.service
>   systemctl disable belleshop@0.1.socket
> 
> I've done that for a few versions now, and it seemed to work OK. There
> is a little problem though. The old versions are still loaded:
> 
>   $ systemctl --no-legend --all list-units belleshop@*
>   belleshop@0.110.service loaded active   running Belleshop server
>   belleshop@0.34.service  loaded inactive deadBelleshop server
>   belleshop@0.36.service  loaded inactive deadBelleshop server
>   belleshop@0.37.service  loaded inactive deadBelleshop server
>   [...]
>   belleshop@0.110.socket  loaded active   running Belleshop socket
>   belleshop@0.34.socket   loaded inactive deadBelleshop socket
>   belleshop@0.36.socket   loaded inactive deadBelleshop socket
>   belleshop@0.37.socket   loaded inactive deadBelleshop socket
>   [...]
> 
> Is there any way I can unload these old versions?
> 
> Here are my unit files:
> 
> belleshop@.service:
>   [Unit]
>   Description=Belleshop server
>   Requires=belleshop@%i.socket
>   After=network.target
> 
>   [Service]
>   User=belleshop
>   Group=belleshop
>   ExecStart=/opt/belleshop/bin/belleshop-%i.pyz server --bind 
> unix:/run/belleshop/belleshop-%i.sock
>   ConfigurationDirectory=opt/belleshop/
>   StateDirectory=belleshop
>   CacheDirectory=belleshop
>   RuntimeDirectory=belleshop
>   Environment="SHIV_ROOT=/var/cache/belleshop"
>   RuntimeDirectoryPreserve=yes
>   StandardOutput=journal
>   StandardError=inherit
> 
>   [Install]
>   WantedBy=multi-user.target
> 

This pins all service units

> belleshop@.socket:
>   [Unit]
>   Description=Belleshop socket
> 
>   [Socket]
>   ListenStream=/run/belleshop/belleshop-%i.sock
> 
>   [Install]
>   WantedBy=sockets.target
> 


And this pins all socket units.

Units are not unloaded if they are part of dependency chain, and here
units are Wanted by another unit(s).

I am not sure if reloading systemd will help here. It preserves current
state across reload so it comes up with the same dependencies. There is
really no way to tell systemd that this unit no more exists. It was
never designed for such dynamic reconfiguration.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

  1   2   3   4   5   6   7   8   >