Re: [systemd-devel] Custom options and passing options via command line.

2022-05-10 Thread Andrei Borzenkov
On 08.05.2022 20:19, Kamil Jońca wrote:
> I have question about custom options in network interface definitions
> and passing it via command line.
> In currend Debian tools
> 
> (https://manpages.debian.org/buster/ifupdown/interfaces.5.en.html)
> there is a possibility to define custom option and passing it to up/down
> script (see ENVIRONMENT VARIABLES section)
> Is it possible in *.network files?
> 
> Moreover: can I pass option during interface up/down?
> For example, in my if-up*/if-down* scripts I have code for replacing (or
> not!) default route when needed.[1]
> 
> Then I can execute something like:
> 
> --8<---cut here---start->8---
> ifup wlan0 -o replacedefaultroute=on
> --8<---cut here---end--->8---
> 
> how I can achieve this with networkctl (or other systemd tool)?
> 
> KJ
> [1]
> in man systemd.network
> I found
> 
> [DHCPV4]
> UseRoutes=
> 
> but I am not sure if this is about default routes or only classless
> static routes
> 

Default route is UseGateway option which defaults to the value of
UseRoutes option.


Re: [systemd-devel] systemd tries to terminate a process that seems to have exited

2022-05-09 Thread Andrei Borzenkov
On 09.05.2022 23:43, Yuri Kanivetsky wrote:
> Hi Andrei,
> 
> Thanks for the suggestion. It becomes more verbose, but it still seems
> like `systemd` fails to notice that `gnome-keyring` exited:
> 

Probably

...

> 
> The child exits:
> 
> May 09 17:52:47 cb6d1c84f84e gnome-keyring-daemon[314]: -- main:
> return 0, gkd-main.c:1210
> May 09 17:52:47 cb6d1c84f84e gnome-keyring-d[314]: -- main: return
> 0, gkd-main.c:1210
> May 09 17:52:47 cb6d1c84f84e systemd[106]: Child 314
> (gnome-keyring-d) died (code=exited, status=0/SUCCESS)
> May 09 17:52:47 cb6d1c84f84e systemd[106]: gnome-keyring.service:
> Child 314 belongs to gnome-keyring.service.
> May 09 17:52:47 cb6d1c84f84e systemd[106]: Received SIGCHLD from
> PID 314 (n/a).

What I miss is "cgroup is empty" message. For comparison:

May 10 07:56:16 bor-Latitude-E5450 systemd[1593]: Received SIGCHLD from
PID 73346 (sleep).

May 10 07:56:16 bor-Latitude-E5450 systemd[1593]: Child 73346 (sleep)
died (code=exited, status=0/SUCCESS)

May 10 07:56:16 bor-Latitude-E5450 systemd[1593]: oneshot.service: Child
73346 belongs to oneshot.service.

May 10 07:56:16 bor-Latitude-E5450 systemd[1593]: oneshot.service:
Control group is empty.

May 10 07:56:16 bor-Latitude-E5450 systemd[1593]: oneshot.service:
Succeeded.

May 10 07:56:16 bor-Latitude-E5450 systemd[1593]: oneshot.service:
Service will not restart (restart setting)

May 10 07:56:16 bor-Latitude-E5450 systemd[1593]: oneshot.service:
Changed stop-sigterm -> dead

May 10 07:56:16 bor-Latitude-E5450 systemd[1593]: oneshot.service: Job
986 oneshot.service/start finished, result=done

May 10 07:56:16 bor-Latitude-E5450 systemd[1593]: Finished test oneshot
forking service.


You never mentioned your systemd version so it is hard to say anything.
But it sounds like systemd issue in one specific version you are using.

> 
> The org.freedesktop.secrets service is activated:
> 
> May 09 17:52:47 cb6d1c84f84e dbus-daemon[124]: [session uid=1000
> pid=124] Activating service name='org.freedesktop.secrets' requested
> by ':1.16' (uid=1000 pid=243 comm="/usr/libexec/xdg-desktop-portal ")
> May 09 17:52:47 cb6d1c84f84e gnome-keyring-d[348]: -- main: 
> gkd-main.c:1046
> May 09 17:52:47 cb6d1c84f84e org.freedesktop.secrets[348]:
> gnome-keyring-daemon: no process capabilities, insecure memory might
> get used
> May 09 17:52:47 cb6d1c84f84e gnome-keyring-daemon[348]: couldn't
> access control socket: /run/user/1000/keyring/control: No such file or
> directory
> May 09 17:52:47 cb6d1c84f84e gnome-keyring-d[348]: couldn't access
> control socket: /run/user/1000/keyring/control: No such file or
> directory
> May 09 17:52:47 cb6d1c84f84e dbus-daemon[124]: [session uid=1000
> pid=124] Successfully activated service 'org.freedesktop.secrets'
> 
> The gnome-keyring service times out:
> 
> May 09 17:54:17 cb6d1c84f84e systemd[106]: gnome-keyring.service:
> State 'stop-sigterm' timed out. Killing.
> May 09 17:54:17 cb6d1c84f84e systemd[106]: gnome-keyring.service:
> Failed with result 'timeout'.
> May 09 17:54:17 cb6d1c84f84e systemd[106]: gnome-keyring.service:
> Service will not restart (restart setting)
> May 09 17:54:17 cb6d1c84f84e systemd[106]: gnome-keyring.service:
> Changed stop-sigterm -> failed
> May 09 17:54:17 cb6d1c84f84e systemd[106]: gnome-keyring.service:
> Job 167 gnome-keyring.service/start finished, result=failed
> May 09 17:54:17 cb6d1c84f84e systemd[106]: Failed to start Start
> gnome-keyring for the Secrets Service, and PKCS #11.
> May 09 17:54:17 cb6d1c84f84e systemd[106]: gnome-keyring.service:
> Unit entered failed state.
> 
> More info here:
> 
> https://gist.github.com/x-yuri/b12e8178a621372a4aa62c60693af37b#file-b-journal-gnome-keyring-gist-md
> 
> Do you know any reason a process can remain alive after exit() or
> return from main()? Any threads started by PAM or anything
> dbus-related (wild guesses on my part)? Anything else I can check?
> 
> Regards,
> Yuri
> 
> On Thu, May 5, 2022 at 8:19 AM Andrei Borzenkov  wrote:
>>
>> On 05.05.2022 04:41, Yuri Kanivetsky wrote:
>>> Hi,
>>>
>>> This might be not a systemd issue. But the behavior is weird, and I'm not 
>>> sure.
>>>
>>> I'm trying to run GNOME in a docker container. And gnome-keyring fails to 
>>> start:
>>>
>>> https://gist.github.com/x-yuri/c3c715ea6355633de4546ae957a66410
>>>
>>> I added debug statements, and in the log I see:
>>>
>>> May 02 05:09:02 ab6aaba04124 systemd[109]: Starting Start
>>> gnome-keyring for the Secrets Service, and PKCS #11...
>>> May 02 05:09:02 ab6aa

Re: [systemd-devel] systemd tries to terminate a process that seems to have exited

2022-05-04 Thread Andrei Borzenkov
On 05.05.2022 04:41, Yuri Kanivetsky wrote:
> Hi,
> 
> This might be not a systemd issue. But the behavior is weird, and I'm not 
> sure.
> 
> I'm trying to run GNOME in a docker container. And gnome-keyring fails to 
> start:
> 
> https://gist.github.com/x-yuri/c3c715ea6355633de4546ae957a66410
> 
> I added debug statements, and in the log I see:
> 
> May 02 05:09:02 ab6aaba04124 systemd[109]: Starting Start
> gnome-keyring for the Secrets Service, and PKCS #11...
> May 02 05:09:02 ab6aaba04124 gnome-keyring-d[309]: -- main: 1046
> May 02 05:09:02 ab6aaba04124 gnome-keyring-daemon[309]:
> gnome-keyring-daemon: no process capabilities, insecure memory might
> get used
> May 02 05:09:02 ab6aaba04124 gnome-keyring-daemon[309]: --
> fork_and_print_environment: fork(), parent, 653
> May 02 05:09:02 ab6aaba04124 gnome-keyring-daemon[321]: --
> fork_and_print_environment: fork(), child, 684
> May 02 05:09:02 ab6aaba04124 gnome-keyring-daemon[321]: couldn't
> access control socket: /run/user/1000/keyring/control: No such file or
> directory
> May 02 05:09:02 ab6aaba04124 gnome-keyring-daemon[309]: --
> fork_and_print_environment: exit(0), 680
> May 02 05:09:02 ab6aaba04124 gnome-keyring-daemon[321]: -- main:
> return 0, 1210
> May 02 05:10:32 ab6aaba04124 systemd[109]: gnome-keyring.service:
> State 'stop-sigterm' timed out. Killing.
> May 02 05:10:32 ab6aaba04124 systemd[109]: gnome-keyring.service:
> Failed with result 'timeout'.
> May 02 05:10:32 ab6aaba04124 systemd[109]: Failed to start Start
> gnome-keyring for the Secrets Service, and PKCS #11.
> 
...
> 
> I can only reproduce it on Debian 8. Which kind of makes it
> unimportant. But the behavior is so weird (either gnome-keyring is
> blocked in/after exit(), or systemd tries to kill a process that
> exited), that I can't help but think about what is really going on
> there.
> 


So run systemd user instance with debug level logging to see which
process are still left.


Re: [systemd-devel] Splitting sd-boot from systemd/bootctl for enabling sd-boot in Fedora

2022-04-29 Thread Andrei Borzenkov
On 28.04.2022 10:54, Lennart Poettering wrote:
> 
>> * systemd-boot is an additional bootloader, rather than replacing
>>   an existing one, thus increasing the attack surface.
> 
> Hmm, what? "additional bootloader"? Are they suggesting you use grub
> to start sd-boot? I mean, you certainly could do that, but the only
> people I know who do that do that to patch around the gatekeeping that
> the shim people are doing. Technically the boot chain should either be
> [firmware → sd-boot → kernel] or [firmware → shim → sd-boot → kernel]
> (if you buy into the shim thing), and nothing else.
> 

I guess "additional bootloader" in this context means that distribution
cannot use sd-boot as the only bootloader for obvious reason - it is EFI
only. So distribution would need to keep currently used bootloader
anyway. If current bootloader already works on platforms supported by
distribution, what is gained by adding yet another one?


Re: [systemd-devel] Starting one service when another one starts

2022-04-08 Thread Andrei Borzenkov
On 08.04.2022 23:35, Nick Howitt wrote:
> Sorry, for the delay. Big internet outage.
> 
> On 08/04/2022 15:15, Andrei Borzenkov wrote:
>>
>> On 08.04.2022 14:54, Nick Howitt wrote:
>>> Hi,
>>> I apologise if this is not the right place for user help. If it is not,
>>> please point me to the best place.
>>>
>>> I am trying to start a service (clearshare-scheduler) when another
>>> service (siad) starts. Clearshare-scheduler is an odd service. When you
>>> start it it may run for ages (days+) or it may terminate immediately so
>>> I have set it up as a oneshot:
>>>
> clearshare-scheduler.service
>>> [Unit]
>>> Description=Clearshare Scheduler
>>> PartOf=siad.service
>>> After=siad.service
>>>
>>> [Service]
>>> Type=oneshot
>>> Environment="TERM=dumb"
>>> ExecStartPre=-/usr/bin/killall -15 -q /usr/sbin/clearshare-scheduler.sh
>>> ExecStartPre=-/usr/bin/echo "$(/usr/bin/date) Starting scheduler from
>>> systemd" >> /var/log/scheduler.log
>>> ExecStart=/usr/sbin/clearshare-scheduler.sh > /dev/null
>>> ExecStop=-/usr/bin/killall -15 -q /usr/sbin/clearshare-scheduler.sh
>>>
>>> [Install]
>>> WantedBy=multi-user.target
>>>
>>> The siad service looks like:
>>>
> siad.service
>>> [Unit]
>>> Description=Siad
>>> After=syslog.target network.target clearsync.service
>>>
>>> [Service]
>>> Type=simple
>>> OOMScoreAdjust=500
>>> PIDFile=/var/run/siad.pid
>>> EnvironmentFile=/etc/sysconfig/siad
>>> Environment="SIA_DATA_DIR=/var/lib/siad-data"
>>> ExecStartPre=-/usr/bin/killall -15 -q clearshare-scheduler.sh
>>> ExecStartPre=-/usr/bin/rm -f /var/run/siad.pid
>>> ExecStart=/usr/bin/siad $EXTRA_ARGS
>>> ExecStop=/usr/bin/siac stop
>>> WorkingDirectory=/var/lib/sia/
>>> ExecStartPost=/usr/bin/sh -c 'umask 022; /usr/bin/pgrep siad >
>>> /var/run/siad.pid'
>>>
>>> [Install]
>>> WantedBy=multi-user.target
>>>
>>
>> You do not show actual unit names which makes it rather difficult to follow.
> Done. See above
>>
>>> A "systemctl show clearshare-scheduler" lists the PartOf=siad.service as
>>> one of its properties but, in reverse, "systemctl show siad" does not
>>> list the corresponding ConsistsOf property.
>>>
>>> When I start siad, nothing happens to the clearshare-scheduler service.
>>
>> Why do you expect to happen? There is no Wants or Requires in the unit
>> that is /probably/ siad.service so request to start siad.service will
>> not pull in any additional units.
> Perhaps I have misunderstood, but from the documentation I understood 
> you could PartOf in force (in this case) clearshare-scheduler.service to 
> respond when siad.service was stopped or started. Have I misunderstood 
> the docs? I am hoping to not do any changes to the siad.service.
> 

Documentation for PartOf says "limited to stopping and restarting of
units". Nothing about "starting". PartOf complements normal startup
dependencies, not replaces them. And yes, this is confusing, as are the
names of almost any systemd dependency which mean something entirely
different from what these names imply in English.

You can add WantedBy=siad.service to [Install] section of
clearshare-scheduler.service. In general you can always extend Wants by
manually creating necessary links. This does not require you to edit
unit definition itself. You can also create drop-in (although I am not
sure whether they are already supported in your systemd version).

> As an alternative, which does affect the siad.service, is there any way 
> I can run the clearshare-scheduler.sh script from the siad.service? I 
> have tried starting it as a ExecStartPost, but it does not appear to 
> work if the script does not exit immediately. If it runs for a while, 
> then systemd says siad has failed to start.

You can increase TimeoutStartSec.

> I've tried launching it with
> ExecStartPost=-/usr/sbin/clearshare-scheduler.sh

"-" affects command that completed with failure status, in your case
command does not complete so this does not have any effect.

> and
> ExecStartPost=-/usr/sbin/clearshare-scheduler.sh &
> and
> ExecStartPost=-/usr/bin/nohup /usr/sbin/clearshare-scheduler.sh &
> 

sytsemd is not shell, what made you think this would work? If you want
to use shell syntax, you need to invoke shell

/bin/sh -c "/usr/sbin/clearshare-scheduler.sh &"

>>
>>> It does not try to start but it runs when I run it on its own. Have I
>>> misunderstood something?
>>>
>>> My version of systems is systemd-219-78.el7_9.5.
>>>
>>> Thanks,
>>>
>>> Nick
>>



Re: [systemd-devel] Starting one service when another one starts

2022-04-08 Thread Andrei Borzenkov
On 08.04.2022 14:54, Nick Howitt wrote:
> Hi,
> I apologise if this is not the right place for user help. If it is not, 
> please point me to the best place.
> 
> I am trying to start a service (clearshare-scheduler) when another 
> service (siad) starts. Clearshare-scheduler is an odd service. When you 
> start it it may run for ages (days+) or it may terminate immediately so 
> I have set it up as a oneshot:
> 
> [Unit]
> Description=Clearshare Scheduler
> PartOf=siad.service
> After=siad.service
> 
> [Service]
> Type=oneshot
> Environment="TERM=dumb"
> ExecStartPre=-/usr/bin/killall -15 -q /usr/sbin/clearshare-scheduler.sh
> ExecStartPre=-/usr/bin/echo "$(/usr/bin/date) Starting scheduler from 
> systemd" >> /var/log/scheduler.log
> ExecStart=/usr/sbin/clearshare-scheduler.sh > /dev/null
> ExecStop=-/usr/bin/killall -15 -q /usr/sbin/clearshare-scheduler.sh
> 
> [Install]
> WantedBy=multi-user.target
> 
> The siad service looks like:
> 
> [Unit]
> Description=Siad
> After=syslog.target network.target clearsync.service
> 
> [Service]
> Type=simple
> OOMScoreAdjust=500
> PIDFile=/var/run/siad.pid
> EnvironmentFile=/etc/sysconfig/siad
> Environment="SIA_DATA_DIR=/var/lib/siad-data"
> ExecStartPre=-/usr/bin/killall -15 -q clearshare-scheduler.sh
> ExecStartPre=-/usr/bin/rm -f /var/run/siad.pid
> ExecStart=/usr/bin/siad $EXTRA_ARGS
> ExecStop=/usr/bin/siac stop
> WorkingDirectory=/var/lib/sia/
> ExecStartPost=/usr/bin/sh -c 'umask 022; /usr/bin/pgrep siad > 
> /var/run/siad.pid'
> 
> [Install]
> WantedBy=multi-user.target
> 

You do not show actual unit names which makes it rather difficult to follow.

> A "systemctl show clearshare-scheduler" lists the PartOf=siad.service as 
> one of its properties but, in reverse, "systemctl show siad" does not 
> list the corresponding ConsistsOf property.
> 
> When I start siad, nothing happens to the clearshare-scheduler service. 

Why do you expect to happen? There is no Wants or Requires in the unit
that is /probably/ siad.service so request to start siad.service will
not pull in any additional units.

> It does not try to start but it runs when I run it on its own. Have I 
> misunderstood something?
> 
> My version of systems is systemd-219-78.el7_9.5.
> 
> Thanks,
> 
> Nick



Re: [systemd-devel] Antw: [EXT] Re: Q: Difference between AssertPathExists and ConditionPathExists?

2022-03-17 Thread Andrei Borzenkov
On 17.03.2022 14:15, Ulrich Windl wrote:
>>>> Andrei Borzenkov  schrieb am 17.03.2022 um 12:08 in
> Nachricht
> :
>> On Thu, Mar 17, 2022 at 12:32 PM Ulrich Windl
>>  wrote:
>>>
>>> Hi!
>>>
>>> When reading the manual page systemd.unit(5), I'm not quite sure what the 
>> difference between AssertPathExists and ConditionPathExists is:
>>>
>>> (Condition)
>>> If the specified absolute path name does not exist, the condition will fail.
>>>
>>> Vs.
>>>
>>> (Assert)
>>> However, unlike the conditions settings, any assertion setting that is not 
>> met results
>>> in failure of the start job it was triggered by.
>>> 
>>> What does that mean effectively?
>>>
>>
>> Assert makes the start job fail, which triggers any followup failure
>> processing (like failure of other units Requiring this one). Condition
>> silently skips starting of this unit but proceeds normally with
>> starting dependent units.
> 
> OK, ist that "skip" actually a "skip once (and silently) for now", or is it 
> more like a "delay until no longer true"?
> 

Start job is completed without doing anything, there is no delay.


Re: [systemd-devel] Q: Difference between AssertPathExists and ConditionPathExists?

2022-03-17 Thread Andrei Borzenkov
On Thu, Mar 17, 2022 at 12:32 PM Ulrich Windl
 wrote:
>
> Hi!
>
> When reading the manual page systemd.unit(5), I'm not quite sure what the 
> difference between AssertPathExists and ConditionPathExists is:
>
> (Condition)
> If the specified absolute path name does not exist, the condition will fail.
>
> Vs.
>
> (Assert)
> However, unlike the conditions settings, any assertion setting that is not 
> met results
> in failure of the start job it was triggered by.
> 
> What does that mean effectively?
>

Assert makes the start job fail, which triggers any followup failure
processing (like failure of other units Requiring this one). Condition
silently skips starting of this unit but proceeds normally with
starting dependent units.


Re: [systemd-devel] making firewalld an early boot service

2022-03-09 Thread Andrei Borzenkov
On Wed, Mar 9, 2022 at 10:18 AM Michael Biebl  wrote:
>
> Am Mi., 9. März 2022 um 06:49 Uhr schrieb Andrei Borzenkov
> :
> >
> > On 09.03.2022 00:59, Michael Biebl wrote:
> > > Hi,
> > >
> > > I need help with firewalld issue, specifically
> > > https://github.com/firewalld/firewalld/issues/414
> > >
> > > the TLDR: both firewalld.service and cloud-init-local.service hook
> > > into network-pre.target and have a Before=network-pre.target ordering.
> > >
> > > cloud-init-local.service is an early boot service using
> > > DefaultDependencies=no and before sysinit.target.
> > > firewalld.service via DefaultDependencies=yes get's an
> > > After=sysinit.target ordering.
> > >
> > > So we have conflicting requirements and a dependency loop that needs
> > > to be broken by systemd.
> > >
> >
> > Firewalld is red herring here. cloud-init.service has
> >
> > After=networking.service
> > Before=sysinit.target
> >
> > This is a loop which has nothing to do with firewalld.
>
> Afaics firewalld.service is involved here.
> For one, without it installed, there is no such ordering cycle.
>

OK, seems networking.service has DefaultDepencies=no, so yes, without
firewalld it can be moved early.

> To me it looks like cloud-init.service and firewalld.service are tied
> together via this cloud-init-local.service
>

The loop below (from the firewalld issue) does not involve
cloud-init-local.service.

>
> > [1.643638] systemd[1]: sysinit.target: Found ordering cycle on
> > cloud-init.service/start
> > [1.645482] systemd[1]: sysinit.target: Found dependency on
> > networking.service/start
> > [1.647274] systemd[1]: sysinit.target: Found dependency on
> > network-pre.target/start
> > [1.649010] systemd[1]: sysinit.target: Found dependency on
> > firewalld.service/start
> > [1.650718] systemd[1]: sysinit.target: Found dependency on
> > dbus.service/start
> > [1.652294] systemd[1]: sysinit.target: Found dependency on
> > basic.target/start
> > [1.654033] systemd[1]: sysinit.target: Found dependency on
> > sysinit.target/start
> > [1.655528] systemd[1]: sysinit.target: Job cloud-init.service/start
> > deleted to break ordering cycle starting with sysinit.target/start
> >
> >
> > ...
> >
> > >
> > >
> > > I dropped the After=dbus.service polkit.service orderings, as they are
> > > either socket or D-Bus activated services, added an explicit
> > > After=local-fs.target ordering just to be sure and hooked it into
> > > sysinit.target.
> > >
> > > Would you agree that making a firewall service an early boot service
> > > is a good idea?
> >
> > Firewalld cannot be socket activated. The whole reason to have firewall
> > (any firewall) startup service is to instantiate netfilter configuration
> > before networking becomes available. When exactly it is done does not
> > matter - it can well be done as early boot service. But it cannot be
> > delayed until something contacts firewall endpoint. It must be done
> > before network-pre.target.
>
> I don't think i said I want firewalld to become socket activated?
> What I did was drop After=dbus.service and After=polkit.service.
> firewald.service is a Type=dbus service, so already get's an explicit
> After=dbus.socket, Requires=dbus.socket which I think should satisfy
> firewalld's D-Bus requirements, no?
>
> > > Does the above make sense or have I missed something?
> > >
> > > Feedback welcome.
> >
> > firewalld requires D-Bus so it must be started after D-Bus. You cannot
> > start it earlier.
>
> See above, being Type=dbus, it has an explicit Requires/After=dbus.socket.

I do not see how it helps. Firewalld cannot become active before D-Bus
is started. If firewalld.service is ordered before network-pre.target
systemd will wait for firewalld.service to become ready before
activating network-pre.target. If network-pre.target is ordered before
sysinit.target and hence before D-Bus service it means deadlock.

It may work with systemd-networkd which dropped DefaultDependencies
and so could be arbitrarily shuffled in boot sequence, but
network.service is a generic alias that normally points to the actual
implementation. Can you start NetworkManager before sysinit.target?


Re: [systemd-devel] making firewalld an early boot service

2022-03-08 Thread Andrei Borzenkov
On 09.03.2022 00:59, Michael Biebl wrote:
> Hi,
> 
> I need help with firewalld issue, specifically
> https://github.com/firewalld/firewalld/issues/414
> 
> the TLDR: both firewalld.service and cloud-init-local.service hook
> into network-pre.target and have a Before=network-pre.target ordering.
> 
> cloud-init-local.service is an early boot service using
> DefaultDependencies=no and before sysinit.target.
> firewalld.service via DefaultDependencies=yes get's an
> After=sysinit.target ordering.
> 
> So we have conflicting requirements and a dependency loop that needs
> to be broken by systemd.
> 

Firewalld is red herring here. cloud-init.service has

After=networking.service
Before=sysinit.target

This is a loop which has nothing to do with firewalld.

[1.643638] systemd[1]: sysinit.target: Found ordering cycle on
cloud-init.service/start
[1.645482] systemd[1]: sysinit.target: Found dependency on
networking.service/start
[1.647274] systemd[1]: sysinit.target: Found dependency on
network-pre.target/start
[1.649010] systemd[1]: sysinit.target: Found dependency on
firewalld.service/start
[1.650718] systemd[1]: sysinit.target: Found dependency on
dbus.service/start
[1.652294] systemd[1]: sysinit.target: Found dependency on
basic.target/start
[1.654033] systemd[1]: sysinit.target: Found dependency on
sysinit.target/start
[1.655528] systemd[1]: sysinit.target: Job cloud-init.service/start
deleted to break ordering cycle starting with sysinit.target/start


...

> 
> 
> I dropped the After=dbus.service polkit.service orderings, as they are
> either socket or D-Bus activated services, added an explicit
> After=local-fs.target ordering just to be sure and hooked it into
> sysinit.target.
> 
> Would you agree that making a firewall service an early boot service
> is a good idea?

Firewalld cannot be socket activated. The whole reason to have firewall
(any firewall) startup service is to instantiate netfilter configuration
before networking becomes available. When exactly it is done does not
matter - it can well be done as early boot service. But it cannot be
delayed until something contacts firewall endpoint. It must be done
before network-pre.target.

> Does the above make sense or have I missed something?
> 
> Feedback welcome.

firewalld requires D-Bus so it must be started after D-Bus. You cannot
start it earlier.


Re: [systemd-devel] How to find out the processes systemd-shutdown is waiting for?

2022-03-08 Thread Andrei Borzenkov
On 08.03.2022 18:20, Manuel Wagesreither wrote:
> Hi all,
> 
> Am Do, 3. Mär 2022, um 19:02, schrieb Lennart Poettering:
>> On Mi, 02.03.22 17:50, Lennart Poettering (lenn...@poettering.net) wrote:
>>
>>> That said, we could certainly show both the comm field and the PID of
>>> the offending processes. I am prepping a patch for that.
>>
>> See: https://github.com/systemd/systemd/pull/22655
>>
>> Lennart
> 
> now that is some service. Thanks for looking into this that quickly!
> 
> I think we solved our issues, and it seems they were not related to docker at 
> all. The mistake was on our side.
> 
> We were using the PowerOff() method from org.freedesktop.systemd1.Manager 
> [1], which the manpage advices against. When using PowerOff() from 
> org.freedesktop.login1.Manager, which as per the manpage is the preferred way 
> to trigger a shutdown from GUI, things seem to work okay.
> 
> That is, this shows the described issues:
> ```
> dbus-send --system --print-reply --type='method_call' 
> --dest=org.freedesktop.systemd1 /org/freedesktop/systemd1 
> org.freedesktop.systemd1.Manager.PowerOff
> ```

This immediately invokes final shutdown binary without attempting to
stop any unit. So systemd starts killing spree with everything running.
This is actually documented on the page you mention.

> while this works ok:
> ```
> dbus-send --system --print-reply --type='method_call' 
> --dest=org.freedesktop.login1 /org/freedesktop/login1 
> org.freedesktop.login1.Manager.PowerOff boolean:false
> ```
> 
> [1] 
> https://www.freedesktop.org/software/systemd/man/org.freedesktop.systemd1.html#Methods
> [2] 
> https://www.freedesktop.org/software/systemd/man/org.freedesktop.login1.html#Methods
> 
> Posting this here as it might be of interest to someone on the list.
> 
> Best regards,
> Manuel



Re: [systemd-devel] Launching script that needs network before suspend

2022-01-24 Thread Andrei Borzenkov
On 24.01.2022 17:37, Tomáš Hnyk wrote:
> 
> 
> On Monday 24. January 2022, 13:50:48 (+01:00), Andrei Borzenkov wrote:
> 

I posted it in response to the list and you sent personal reply. Please use
reply to all.

>> On Mon, Jan 24, 2022 at 1:14 AM Tomáš Hnyk  wrote:
>>>
>>> Hello,
>>> I have my computer hooked up to an AVR that runs my home cinema and ideally 
>>> I would like the computer to turn off the AVR when I turn it off or suspend 
>>> it. The only way to do this is over network and I wrote a simple script 
>>> that does just that. Hooking it to shutdown was quite easy using 
>>> network.target that is defined when shutting down.
>>>
>>> I am struggling to make it work with suspend though. When I look at the 
>>> logs, terminating network seems to be the first thing that happens when 
>>> suspend is invoked. I tried putting the script to 
>>> /usr/lib/systemd/system-sleep/ and it runs, but only after network si down, 
>>> so it fails. Running the script with systemd-inhibit 
>>> (ExecStart=/usr/bin/systemd-inhibit --what=sleep my_script) tells me that 
>>> "Failed to inhibit: The operation inhibition has been requested for is 
>>> already running".
>>>
>>
>> What network management program are you using?
> Network Manager. I tried putting "systemctl start NetworkManager.service" 
> into the /usr/lib/systemd/system-sleep/ hook but even though the log says 
> network is reestablished, the script still fails.

NetworkManager has own hooks. Unfortunately there is no hook that runs on
suspend/resume - only on interface up/down. You may want to post to NM list
asking whether something like this could be implemented (but it will take
a long time).

Is performing your action on interface down acceptable? If interface stays
up all the time except during suspend or shutdown it looks like workaround.

> 
>>
>>> Is there a way to make this work with service files by specifying that the 
>>> script needs to be run before network is shut down or would I need to run a 
>>> daemon listening for PrepareForSleep as here: 
>>> https://github.com/davidn/av/blob/master/av ?
>>>
>>
>> Yes, this is probably the only generic solution.
>>
> I tried the script I linked and it does not work either (there seems to be a 
> race condition that I am losing). What I am not clear about inhibiting is 
> this: when PrepareForSleep is called and I have a script hooked into it that 
> inhibits sleep, does it inhibit sleep from finishing or from running 
> everything that is triggered by it? To me it seems it will just delay going 
> to sleep, but shutting the network down is not inhibited.

NetworkManage takes sleep lock and subscribes to PrepareForSleep()
signal, so your daemon races with NetworkManager. There is no way
to change it - various programs subscribed to PrepareForSleep() are
not aware of each other at all.

These programs run outside of systemd unit management so you cannot
use "normal" systemd dependencies to order them.


Re: [systemd-devel] Launching script that needs network before suspend

2022-01-24 Thread Andrei Borzenkov
On Mon, Jan 24, 2022 at 1:14 AM Tomáš Hnyk  wrote:
>
> Hello,
> I have my computer hooked up to an AVR that runs my home cinema and ideally I 
> would like the computer to turn off the AVR when I turn it off or suspend it. 
> The only way to do this is over network and I wrote a simple script that does 
> just that. Hooking it to shutdown was quite easy using network.target that is 
> defined when shutting down.
>
> I am struggling to make it work with suspend though. When I look at the logs, 
> terminating network seems to be the first thing that happens when suspend is 
> invoked. I tried putting the script to /usr/lib/systemd/system-sleep/ and it 
> runs, but only after network si down, so it fails. Running the script with 
> systemd-inhibit (ExecStart=/usr/bin/systemd-inhibit --what=sleep my_script) 
> tells me that "Failed to inhibit: The operation inhibition has been requested 
> for is already running".
>

What network management program are you using?

> Is there a way to make this work with service files by specifying that the 
> script needs to be run before network is shut down or would I need to run a 
> daemon listening for PrepareForSleep as here: 
> https://github.com/davidn/av/blob/master/av ?
>

Yes, this is probably the only generic solution.


Re: [systemd-devel] Have I got circular dependencies?

2022-01-23 Thread Andrei Borzenkov
On 23.01.2022 19:42, Wols Lists wrote:
> This is probably a classic "need a clue" problem ... my system has 
> suddenly stopped booting properly, and I guess it's a problem with my 
> custom systemd service.
> 
> Basically, I've configured my raid device on top of dm-integrity, so 
> that needs to be set up before my /home becomes visible. I've tried to 
> say my integrity.service needs to run before the mdadm and lvm services.
> 
> I also seem to remember a mention of dm-integrity in recent (the 
> latest?) release notes?
> 
> The problem being I don't know what - or where - most of the system 
> systemd services and files are.
> 
> Does all this output indicate a problem with my service? Can I just 
> delete my "Before" line, bearing in mind that if the service doesn't run 
> my /home won't appear? (mdadm and lvm pick things up if I run the 
> service manually.)
> 
> And could this be why my service seems occasionally to get randomly 
> killed on boot, leading the problem I described where /home has disappeared?
> 
> Cheers,
> Wol
> 
> anthony@thewolery /etc/systemd/system $ systemctl --version
> systemd 249 (249)
> +PAM -AUDIT -SELINUX -APPARMOR +IMA +SMACK +SECCOMP +GCRYPT +GNUTLS 
> +OPENSSL +ACL +BLKID -CURL -ELFUTILS -FIDO2 +IDN2 -IDN -IPTC +KMOD 
> -LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY -P11KIT -QRENCODE -BZIP2 +LZ4 
> -XZ -ZLIB +ZSTD -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified
> anthony@thewolery /etc/systemd/system $
> 
> anthony@thewolery /etc/systemd/system $ cat integritysetup.service
> [Unit]
> Before=mdmonitor.service lvm2-lvmetad.service
> 
> [Service]
> ExecStart=/usr/local/bin/integritysetup.sh
> 
> [Install]
> WantedBy=default.target
> anthony@thewolery /etc/systemd/system $ systemctl status home.mount
> 
> 
> [8.193416] systemd[1]: Detected architecture x86-64.
> [8.221972] systemd[1]: Hostname set to .
> [9.387275] systemd[1]: Configuration file 
> /etc/systemd/system/scarletdme.service is marked executable. Please 
> remove executable permission bits. Proceeding anyway.
> [9.397748] systemd[1]: Configuration file 
> /etc/systemd/system/integritysetup.service is marked executable. Please 
> remove executable permission bits. Proceeding anyway.
> [9.531750] systemd[1]: Configuration file 
> /etc/systemd/system/gentoo_root_snapshot.timer is marked executable. 
> Please remove executable permission bits. Proceeding anyway.
> [9.563443] systemd[1]: Configuration file 
> /etc/systemd/system/gentoo_root_snapshot.service is marked executable. 
> Please remove executable permission bits. Proceeding anyway.
> [9.610463] systemd[1]: integritysetup.service: Found ordering cycle 
> on sysinit.target/start
> [9.610534] systemd[1]: integritysetup.service: Found dependency on 
> systemd-timesyncd.service/start
> [9.610604] systemd[1]: integritysetup.service: Found dependency on 
> systemd-tmpfiles-setup.service/start
> [9.610673] systemd[1]: integritysetup.service: Found dependency on 
> local-fs.target/start
> [9.610740] systemd[1]: integritysetup.service: Found dependency on 
> home-ISO.automount/start
> [9.610807] systemd[1]: integritysetup.service: Found dependency on 
> home.mount/start
> [9.610872] systemd[1]: integritysetup.service: Found dependency on 
> integritysetup.service/start

Where dependency to /home comes from? It is not in your unit file.

Otherwise normal services are ordered by default after sysinit.target and
local file systems are ordered before sysinit.target so you have loop. Add
DefaultDependencies=no to your service definition.


Re: [systemd-devel] eth2: Failed to rename network interface 6 from 'eth2' to 'eno1': File exists

2022-01-04 Thread Andrei Borzenkov
On Tue, Jan 4, 2022 at 4:53 PM Harald Dunkel  wrote:
>
> Hi folks,
>
> after the upgrade from Buster to Bullseye (including the migration from
> sysv init to systemd) the network interface names were messed up on
> several hosts. Apparently udev stumbles over a naming conflict:
>
> # journalctl -b | egrep -i e1000e\|igb\|rename\|eth\enp\|eno
> Jan 03 11:30:14 nasl002b.example.com kernel: ACPI: Added 
> _OSI(Linux-Lenovo-NV-HDMI-Audio)
> Jan 03 11:30:14 nasl002b.example.com kernel: igb: Intel(R) Gigabit Ethernet 
> Network Driver
> Jan 03 11:30:14 nasl002b.example.com kernel: igb: Copyright (c) 2007-2014 
> Intel Corporation.
> Jan 03 11:30:14 nasl002b.example.com kernel: e1000e: Intel(R) PRO/1000 
> Network Driver
> Jan 03 11:30:14 nasl002b.example.com kernel: e1000e: Copyright(c) 1999 - 2015 
> Intel Corporation.
> Jan 03 11:30:14 nasl002b.example.com kernel: e1000e :00:19.0: Interrupt 
> Throttling Rate (ints/sec) set to dynamic conservative mode
> Jan 03 11:30:14 nasl002b.example.com kernel: igb :02:00.0: added PHC on 
> eth0
> Jan 03 11:30:14 nasl002b.example.com kernel: igb :02:00.0: Intel(R) 
> Gigabit Ethernet Network Connection
> Jan 03 11:30:14 nasl002b.example.com kernel: igb :02:00.0: eth0: 
> (PCIe:5.0Gb/s:Width x4) a0:36:9f:00:06:1c
> Jan 03 11:30:14 nasl002b.example.com kernel: igb :02:00.0: eth0: PBA No: 
> G15139-001
> Jan 03 11:30:14 nasl002b.example.com kernel: igb :02:00.0: Using MSI-X 
> interrupts. 8 rx queue(s), 8 tx queue(s)
> Jan 03 11:30:14 nasl002b.example.com kernel: igb :02:00.1: added PHC on 
> eth1
> Jan 03 11:30:14 nasl002b.example.com kernel: igb :02:00.1: Intel(R) 
> Gigabit Ethernet Network Connection
> Jan 03 11:30:14 nasl002b.example.com kernel: igb :02:00.1: eth1: 
> (PCIe:5.0Gb/s:Width x4) a0:36:9f:00:06:1d
> Jan 03 11:30:14 nasl002b.example.com kernel: igb :02:00.1: eth1: PBA No: 
> G15139-001
> Jan 03 11:30:14 nasl002b.example.com kernel: igb :02:00.1: Using MSI-X 
> interrupts. 8 rx queue(s), 8 tx queue(s)
> Jan 03 11:30:14 nasl002b.example.com kernel: e1000e :00:19.0 :00:19.0 
> (uninitialized): registered PHC clock
> Jan 03 11:30:14 nasl002b.example.com kernel: igb :02:00.2: added PHC on 
> eth2
> Jan 03 11:30:14 nasl002b.example.com kernel: igb :02:00.2: Intel(R) 
> Gigabit Ethernet Network Connection
> Jan 03 11:30:14 nasl002b.example.com kernel: igb :02:00.2: eth2: 
> (PCIe:5.0Gb/s:Width x4) a0:36:9f:00:06:1e
> Jan 03 11:30:14 nasl002b.example.com kernel: igb :02:00.2: eth2: PBA No: 
> G15139-001
> Jan 03 11:30:14 nasl002b.example.com kernel: igb :02:00.2: Using MSI-X 
> interrupts. 8 rx queue(s), 8 tx queue(s)
> Jan 03 11:30:14 nasl002b.example.com kernel: igb :02:00.3: added PHC on 
> eth3
> Jan 03 11:30:14 nasl002b.example.com kernel: igb :02:00.3: Intel(R) 
> Gigabit Ethernet Network Connection
> Jan 03 11:30:14 nasl002b.example.com kernel: igb :02:00.3: eth3: 
> (PCIe:5.0Gb/s:Width x4) a0:36:9f:00:06:1f
> Jan 03 11:30:14 nasl002b.example.com kernel: igb :02:00.3: eth3: PBA No: 
> G15139-001
> Jan 03 11:30:14 nasl002b.example.com kernel: igb :02:00.3: Using MSI-X 
> interrupts. 8 rx queue(s), 8 tx queue(s)
> Jan 03 11:30:14 nasl002b.example.com kernel: igb :02:00.2 eth4: renamed 
> from eth2
> Jan 03 11:30:14 nasl002b.example.com kernel: e1000e :00:19.0 eth2: (PCI 
> Express:2.5GT/s:Width x1) 00:1e:67:19:34:6d
> Jan 03 11:30:14 nasl002b.example.com kernel: e1000e :00:19.0 eth2: 
> Intel(R) PRO/1000 Network Connection
> Jan 03 11:30:14 nasl002b.example.com kernel: e1000e :00:19.0 eth2: MAC: 
> 10, PHY: 11, PBA No: 0100FF-0FF
> Jan 03 11:30:14 nasl002b.example.com kernel: igb :02:00.3 eth5: renamed 
> from eth3
> Jan 03 11:30:14 nasl002b.example.com kernel: e1000e :05:00.0: Interrupt 
> Throttling Rate (ints/sec) set to dynamic conservative mode
> Jan 03 11:30:14 nasl002b.example.com kernel: e1000e :05:00.0 :05:00.0 
> (uninitialized): registered PHC clock
> Jan 03 11:30:14 nasl002b.example.com kernel: e1000e :05:00.0 eth3: (PCI 
> Express:2.5GT/s:Width x1) 00:1e:67:19:34:6c
> Jan 03 11:30:14 nasl002b.example.com kernel: e1000e :05:00.0 eth3: 
> Intel(R) PRO/1000 Network Connection
> Jan 03 11:30:14 nasl002b.example.com kernel: e1000e :05:00.0 eth3: MAC: 
> 3, PHY: 8, PBA No: 1000FF-0FF
> Jan 03 11:30:15 nasl002b.example.com kernel: igb :02:00.1 enp2s0f1: 
> renamed from eth1
> Jan 03 11:30:15 nasl002b.example.com kernel: igb :02:00.0 eno1: renamed 
> from eth0
> Jan 03 11:30:15 nasl002b.example.com kernel: e1000e :05:00.0 enp5s0: 
> renamed from eth3
> Jan 03 11:30:15 nasl002b.example.com systemd-udevd[416]: eth2: Failed to 
> rename network interface 6 from 'eth2' to 'eno1': File exists

You have two interfaces which export the same onboard interface index.
There is not much udev can do here; the only option is to disable
onboard interface name policy. The attributes that are used by udev
are "acpi_index"  and 

Re: [systemd-devel] After= and Wants= doesn't seem to have an effect

2021-12-20 Thread Andrei Borzenkov
On 20.12.2021 17:05, Christopher Wong wrote:
>> # /etc/systemd/system/iris-detection.service
>> [Unit]
>> Description=Iris detection
>> PartOf=opticsd.service
> 
> 
> How can you tell that it is a loop? iris-detection.service doesn't have any 
> After= as you stated below.

Yes, sorry, you are right.

> Is it due to the PartOf=opticsd.service?
> 

I do not think so. Still, loop is possible due to some other dependencies, it 
is also
possible that actual unit definitions are different (e.g. units files have been 
changed
after systemd read them).

Running with debig log level may give some more hints.

> 
> Best Regards,
> 
> Christopher Wong
> 
> ____
> From: systemd-devel  on behalf 
> of Andrei Borzenkov 
> Sent: Monday, December 20, 2021 1:27:42 PM
> To: systemd-devel@lists.freedesktop.org
> Subject: Re: [systemd-devel] After= and Wants= doesn't seem to have an effect
> 
> On 20.12.2021 15:06, Christopher Wong wrote:
>> # /etc/systemd/system/iris-detection.service
>> After=temperature-controller.service
>>
>> # /usr/lib/systemd/system/temperature-controller.service
>> After=iris-detection.service
> 
> This is loop and systemd is free to break it by ignoring some dependency.
> 



Re: [systemd-devel] After= and Wants= doesn't seem to have an effect

2021-12-20 Thread Andrei Borzenkov
On 20.12.2021 15:06, Christopher Wong wrote:
> # /etc/systemd/system/iris-detection.service
> After=temperature-controller.service
> 
> # /usr/lib/systemd/system/temperature-controller.service
> After=iris-detection.service

This is loop and systemd is free to break it by ignoring some dependency.


Re: [systemd-devel] services stopping order during shutdown

2021-12-07 Thread Andrei Borzenkov
On 08.12.2021 08:35, Prashantkumar dhotre wrote:
> Hi,
> Is there a batching of service stops by systemd during shutdown.
> In journal logs, I see a batch of 40 odd 'Stopping' messages and then the
> next batch is seen after few seconds (4-6 seconds)
> Is this by design ?
> I am looking for a faster way to shutdown. Is there any config that can
> speed up service stops during shutdown (like  avoid batching )?
> Thanks
> Prashant
> 

Units are stopped in reverse order of dependency. If unit B has After: A, then
unit B is (requested to be) stopped first, systemd waits until stopping 
completes
and then proceeds with stopping unit A. Unrelated units are stopped 
concurrently.


Re: [systemd-devel] How does udev determine onboard interface names

2021-12-02 Thread Andrei Borzenkov
On 02.12.2021 23:39, Ian Pilcher wrote:
> I.e., how does it determine that a particular interface is an on-board
> interface, and how does it determine the "number" of such an interface?
> 
> Thanks!
> 

It is looking at sysfs attributes (acpi_index, index and some others). Details
are in src/udev/udev-builtin-net_id.c, function dev_pci_onboard().


Re: [systemd-devel] Ordering services issue. Trying to start ptp4l in bonding setup fails as bonding appears to take a while.

2021-12-01 Thread Andrei Borzenkov
On 01.12.2021 17:20, Brian Hutchinson wrote:
> Hi,
> 
> I'm on embedded imx8 mm platform and trying to order services such that
> ptp4l (LinuxPTP) is started after a bond is created between two DSA network
> interfaces on my Microchip Ethernet Switch.
> 
> No matter what I try with BindsTo, Wants=, Requires=, Before=, After=, when
> the board boots and I watch the console output I see systemd start the
> ptp4l service before the bond is actually up which results in ptp4l failing
> to start.
> 
...> 
> Is it also possible to use carrier state in .service file?
> 

I do not think it is possible. I have seen similar request (possibility to
initiate action when interface is up) more than once, but so far nothing
happened. 

This would be similar to NetworkManager dispatcher script.

It does not really fit into service dependency at all.


Re: [systemd-devel] Systemd setup DSA interfaces in port mode and bond them together?

2021-11-17 Thread Andrei Borzenkov
On 18.11.2021 03:20, Brian Hutchinson wrote:
> Yet another update, I was able to get it working .. but feel like it is a
> hack so comments welcome ... see below:
> 
> On Wed, Nov 17, 2021 at 12:26 AM Brian Hutchinson 
> wrote:
> 
>> Update below
>>
>> On Tue, Nov 16, 2021 at 2:27 PM Brian Hutchinson 
>> wrote:
>>
>>> Hi Mikulėnas,
>>>
>>> On Tue, Nov 16, 2021, 3:12 AM Mantas Mikulėnas  wrote:
>>>
 Most of this looks like it could be done with systemd-networkd to create
 a bond .netdev, with a small oneshot service for i2c. (What's the exact
 criteria for when it should be run? Does it depend on bond0 being there,
 does it need to be last, etc?)

>>>
>>> It can be last in the startup chain I guess, don't know what other
>>> systemd things that might need the network to be up before the last unit
>>> file runs.
>>>
>>> I start linuxptp too so I would have the unit file that starts ptp4l
>>> start after the bond was created etc.
>>>
>>> Same thing for the i2c command to enable the switch.
>>>
>>> Regards,
>>>
>>> Brian
>>>
>>>
 On Tue, Nov 16, 2021, 02:58 Brian Hutchinson 
 wrote:

> Hi,
>
> I'm on a IMX8 platform and have a Microchip KSZ9567 Ethernet switch.  I
> can use IP commands to manually bring lan1 and lan2 interfaces up and then
> create a redundant/failover bond ... but I'm having difficulty figuring 
> out
> how to do this the "systemd" way.
>
> My first attempt was to just have systemd run a script of all the
> commands I do manually but during system startup there appears to be race
> conditions so I have to set my service type to "Idle" and sometimes even
> that doesn't work. So I want to exploit any systemd support for DSA and
> bonding.
>
> Here is script my manual steps which is what I want systemd to
> ultimately do:
>
> #!/bin/bash
>
> # Create a redundant bond between ksz9567 DSA lan1 and lan2 interfaces
>
> # Load bonding kernel module
> modprobe bonding
>
> # Bring up CPU interface (cpu to switch port 7 - the RGMII link)
> ip link set eth0 up
>
> # Create a bond
> echo +bond0 > /sys/class/net/bonding_masters
>
> # Set mode to active-backup (redundancy failover)
> echo active-backup > /sys/class/net/bond0/bonding/mode
>
> # Set time it takes (in ms) for slave to move when a link goes down
> echo 1000 > /sys/class/net/bond0/bonding/miimon
>
> # Add slaves to bond
>
> echo +lan1 > /sys/class/net/bond0/bonding/slaves
> echo +lan2 > /sys/class/net/bond0/bonding/slaves
>
> # Set IP and netmask of the bond
> ip addr add 192.168.0.4/24 dev bond0
>
> # And bring bond up.  Pings and network connectivity should work now
> ip link set bond0 up
>
> # For a board that doesn't have Ethernet switch hardware strapped to
> enable at boot .. enable it now
> i2cset -f -y 0 0x5f 0x03 0x00 0x01 i
>
> Thanks for any information, pointers etc.
>
> Regards,
>
> Brian
>

>> So not sure I'm doing this right.  eth0 needs to be up before lan1 and
>> lan2 can be added to the bond.  Not quite sure how to do that with systemd
>> but I made the following files and see some progress but ping doesn't work
>> so appears I have no network connectivity:
>>
>> root@imx8mmevk:/etc/systemd/network# cat 10-bond1.netdev
>> [NetDev]
>> Name=bond1
>> Kind=bond
>>
>> [Bond]
>> Mode=active-backup
>> PrimaryReselectPolicy=failure
>> MIIMonitorSec=2s
>>
>> root@imx8mmevk:/etc/systemd/network# cat 10-bond1.network
>> [Match]
>> Name=bond1
>>
>> [Network]
>> Address=192.168.0.4/24
>>
>> root@imx8mmevk:/etc/systemd/network# cat 20-lan1.network
>> [Match]
>> Name=lan1
>>
>> [Network]
>> Bond=bond1
>> PrimarySlave=true
>>
>> root@imx8mmevk:/etc/systemd/network# cat 30-lan2.network
>>
>> [Match]
>> Name=lan2
>>
>> [Network]
>> Bond=bond
>>
>> ip link list
>> 1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode
>> DEFAULT group default qlen 1000
>>link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>> 2: eth0:  mtu 1506 qdisc mq state UP mode
>> DEFAULT group default qlen 1000
>>link/ether f0:1f:af:6b:b2:17 brd ff:ff:ff:ff:ff:ff
>> 3: lan1@eth0:  mtu 1500 qdisc noop state DOWN mode
>> DEFAULT group default qlen 1000
>>link/ether f0:1f:af:6b:b2:17 brd ff:ff:ff:ff:ff:ff
>> 4: lan2@eth0:  mtu 1500 qdisc noop state DOWN mode
>> DEFAULT group default qlen 1000
>>link/ether f0:1f:af:6b:b2:17 brd ff:ff:ff:ff:ff:ff
>> 5: bond1:  mtu 1500 qdisc
>> noqueue state DOWN mode DEFAULT group default qlen 1000
>>link/ether be:87:0a:9b:13:03 brd ff:ff:ff:ff:ff:ff
>>
>> cat /proc/net/bonding/bond1
>> Ethernet Channel Bonding Driver: v5.10.69
>>
>> Bonding Mode: fault-tolerance (active-backup)
>> Primary Slave: None
>> Currently Active Slave: None
>> MII Status: down
>> MII Polling Interval (ms): 2000
>> Up Delay (ms): 0
>> Down Delay (ms): 0
>> Peer Notification Delay (ms): 0
>>

Re: [systemd-devel] systemd --user fails to start a user service at the first time

2021-10-29 Thread Andrei Borzenkov
On 29.10.2021 19:24, Han wrote:
> I have a follow-up question inline. Thanks.
> 
> On Thu, Oct 28, 2021 at 10:47 PM Han  wrote:
> 
>>
>> On Thu, Oct 28, 2021 at 10:25 PM Andrei Borzenkov 
>> wrote:
>>
>>> On 29.10.2021 04:54, Han wrote:
>>>> Hi,
>>>>
>>>> I'm a newbie to systemd. I encountered a strange problem when using
>>>> systemd user
>>>> service in Debian 10 (hardware: Raspberry Pi 4), systemd version 241.
>>>>
>>>> I posted this question on stackoverflow but didn't get answers yet.
>>> Hence
>>>> trying to ask here. My apologies if this is too basic.
>>>>
>>>>1. I created a new service unit file at here:
>>>>/home/pi/.config/systemd/user/foo.service
>>>>
>>>> its content looks like this:
>>>>
>>>> [Service]
>>>> ExecStart=/home/pi/test/foo
>>>> WorkingDirectory=/home/pi/test
>>>>
>>>>
>>>>1. I tried to start this service, but it failed:
>>>>
>>>> $ systemctl --user start foo
>>>> Failed to start foo.service: Unit foo.se
>>>
>>> Does it work after
>>>
>>> systemctl --user daemon-reload
>>>
>>> ?
>>>
>>
>> Yes, it worked after `daemon-reload`.  Thank you so much!
>>
> 
> 
> "daemon-reload" reloads all unit files in the system.  It seems to me such
> a big remedy for starting a single service.  Is this the expected workflow
> or a workaround?
> 

Normally systemd should load new unit definition that is not yet present
in memory automatically on first reference. Daemon-reload is needed when
unit definition changed since it has been cached.

> Also I tried to add a 2nd service "foo2.service" in the same way,  now I
> don't have to run "daemon-reload" and it can start.  I'm wondering why.
> 

That is expected behavior.


Re: [systemd-devel] systemd --user fails to start a user service at the first time

2021-10-28 Thread Andrei Borzenkov
On 29.10.2021 04:54, Han wrote:
> Hi,
> 
> I'm a newbie to systemd. I encountered a strange problem when using
> systemd user
> service in Debian 10 (hardware: Raspberry Pi 4), systemd version 241.
> 
> I posted this question on stackoverflow but didn't get answers yet. Hence
> trying to ask here. My apologies if this is too basic.
> 
>1. I created a new service unit file at here:
>/home/pi/.config/systemd/user/foo.service
> 
> its content looks like this:
> 
> [Service]
> ExecStart=/home/pi/test/foo
> WorkingDirectory=/home/pi/test
> 
> 
>1. I tried to start this service, but it failed:
> 
> $ systemctl --user start foo
> Failed to start foo.service: Unit foo.se

Does it work after

systemctl --user daemon-reload

?

rvice not found.
> 
> However, systemd can list this unit file when doing this:
> 
> $systemctl --user list-unit-files --type service | grep foo
> foo.service  static
> 
> Moreover, when I added [Install] section in the unit file:
> 
> [Install]
> WantedBy=multi-user.target
> 

User instance does not have this target.

> and run $systemctl --user enable foo , it worked.
> 
> Even more, after that I removed the unit file, and recreated the unit file
> without the [Install] section, now I start the service and the original
> problem is no longer seen.
> 
> So it seems like only when I try to create a new user service for the first
> time on the system, without using [Install], it will fail to start.
> 
> Any ideas why this is happening? (btw, I don't want to have [Install] for
> this service.)
> 
> Or is this a known issue fixed in a later release?
> 
> Thanks
> 
> Han
> 



Re: [systemd-devel] PIDFile creation logic

2021-10-18 Thread Andrei Borzenkov
On 18.10.2021 23:08, Silvio Knizek wrote:
> Am Montag, dem 18.10.2021 um 12:43 -0700 schrieb Kenneth Porter:
>> I just installed the new-to-EPEL ndppd service and am seeing this in my log:
>>
>> Oct 17 21:10:08 saruman systemd: Can't open PID file
>> /var/run/ndppd/ndppd.pid (yet?) after start: No such file or directory
>>

That is just an information. May be it could be downgraded to debug, at
least initially.

>> Examining the source, I see that the pidfile is created by the child
>> process, not the parent. I'm guessing that systemd is expecting the pidfile
>> to exist when the parent exits? (I want to file the issue on the upstream
>> program and want to make sure I understand how this should work.)
>>
>> Source in question. Note how daemonize() forks and exits and main() invokes
>> daemonize and then creates the pidfile. I'm thinking that daemonize()
>> should create the pidfile before it invokes exit().
>>
>> 
>>
> Hi,
> 
> just don't demonize and don't use a PIDFile= at all. systemd is
> actually quite apt in figuring out which process is the right main one.

It is not about "main process". It is about notifying systemd that your
service is ready and systemd can proceed with After dependencies.
Without PIDFile your service is "ready" as soon as it forked. This most
likely is not correct.

Whether service developers are actually careful to only create PID file
at the right time is unknown.

If nothing depends on service availability Type=simple is easier.

> Also, the ndppd 0.2.5 release is 10 years old and doesn't look
> maintained anymore.
> OTOH, systemd-networkd itself has inbuilt NDPProxy capabilities.
> 
> BR
> Silvio
> 



Re: [systemd-devel] What are the use cases of journalctl --flush ?

2021-09-22 Thread Andrei Borzenkov
On Wed, Sep 22, 2021 at 9:27 AM  wrote:

>
> Now that the operation of flush can be done automatically when you switch 
> from Storage=volatile to #Storage=volatile, why do we still need journalctl 
> --flush?
>

To switch from volatile storage to persistent storage on boot as
explained in the man page. On boot /var may not be available
initially, so journald starts with /run and flush copies logs from
/run to /var and switches to persistent storage.


Re: [systemd-devel] Examples to distinguish Before=/After= and Wants=/Requires=/BindsTo=

2021-09-15 Thread Andrei Borzenkov
On 15.09.2021 18:15, Manuel Wagesreither wrote:
> Hello all,
> 
> I'm onboarding some collegues who don't have much experience with systemd. 
> One thing I would like to focus on is the difference between Before=/After= 
> and Wants=/Requires=/BindsTo in systemd units.
> 
> I think it would get immediately clear if could provide them an example where 
> we want one but not the other. Unfortunately I've got problems coming up with 
> such an example. In my use cases, whenever I needed an After= I needed an 
> Wants= as well.
> 
> Can you come up with something good?
> 

No. B After A means - select start job for B for execution after start
job for A completes. This directive is only meaningful if you guarantee
that both start jobs are present in the queue. And the only way to
ensure it is to use Wants (or Requires as variant).

If service B really needs service A to be started before it itself can
be started, you must use After and Wants, otherwise you are open to race
conditions. And if service B does not care if service A is started, then
you do not need After in the first place.

Of course one can try to ensure that all start jobs are present in queue
by some external means. Like making all units to be WantedBy some
super-unit which is called ... default.target (surprise). But that does
not change underlying requirement, just restricts working case to
starting one single unit. Presumably on system boot :)


Re: [systemd-devel] systemd-udevd: Race condition when rule starts both a systemd-mount and an unit accessing that mount

2021-09-04 Thread Andrei Borzenkov
On 01.09.2021 14:39, Manuel Wagesreither wrote:
> Am Mi, 25. Aug 2021, um 18:51, schrieb Andrei Borzenkov:
>> On Wed, Aug 25, 2021 at 3:44 PM Andrei Borzenkov  wrote:
>> ...
>>>> Here's the udev rule:
>>>> ```
>>>> ACTION=="add", SUBSYSTEMS=="usb", SUBSYSTEM=="block", KERNEL=="*[0-9]*", 
>>>> ENV{ID_FS_USAGE}=="filesystem", TAG+="systemd", 
>>>> ENV{SYSTEMD_WANTS}+="start-standalone-mender-deployment@media-$name.service",
>>>>  RUN{program}+="/usr/bin/systemd-mount --no-block --automount=no 
>>>> --options=ro --collect $devnode /media/$name"
>>>> ```
>>>>
>>>> And here's the systemd service:
>>>> It is templated and gets instantiated with "media-sdb1". It therefore has 
>>>> an "After=media-sdb1.mount". I suspect Systemd-udevd executes the 
>>>> ENV{SYSTEMD_WANTS} part before the RUN{program} part. Hence, 
>>>> "media-sdb1.mount" doesn't yet exist when the service gets started, as it 
>>>> gets created a tad later by systemd-mount.
>>>>
>>>> ```
>>>> [Unit]
>>>> Description=Start standalone Mender deployment (%i)
>>>> After=%i.mount
>>>>
>>>> [Service]
>>>> Type=oneshot
>>>> Restart=no
>>>> ExecStart=/bin/sh /usr/bin/start-standalone-mender-deployment.sh /%I
>>>> ```
>>>>
>> ...
>>>
>>> Hmm ... if systemd-mount --property accepts Wants and Before, your
>>> mount unit could pull in your service unit. I cannot test right now.
>>>
>>
>> Yes, this seems to work, so in principle
>>
>> RUN{program}+="/usr/bin/systemd-mount --no-block --automount=no
>> --options=ro --collect --property
>> Wants=start-standalone-mender-deployment@media-$name.service $devnode
>> /media/$name"
>>
>> is possible. Unfortunately this starts unit even if mount fails and
>> systemd-mount does not accept RequiredBy property". It is still
>> possible to add Requires to service itself.
>>
>> [Unit]
>> Description=Start standalone Mender deployment (%i)
>> After=%i.mount
>> Requires=%i.mount
>>
>> This will fail the service start job if the mount job fails.
>>
>> Wants on mount unit pulls in service, so we are guaranteed to always
>> have both start jobs - for mount and for service and dependencies are
>> observed.
>>
> 
> I was unaware of the --property option of systemd-mount. It seems to be 
> exactly what I was looking for.
> 
> Thank you!
> 
> Unfortunately, while testing, I encountered problems with systemd-mount.
> 
> Sporadically, `systemd-mount /dev/sdb1 /media/sdb1` results in the following:
> ```
> $ journalctl -fu systemd-udevd -u media-sdb1.mount -u dev-sdb1.device -u 
> systemd-fsck@dev-sdb1.service
> 15:55:46 systemd[1]: media-sdb1.mount: Failed to open 
> /run/systemd/transient/media-sdb1.mount: No such file or directory
> 15:56:46 systemd-udevd[57294]: sdb1: Spawned process '/usr/bin/systemd-mount 
> /dev/sdb1 /media/sdb1' [57295] is taking longer than 59s to complete

This is not expected with --no-block

> 15:56:46 systemd-udevd[3019]: sdb1: Worker [57294] processing SEQNUM=6665 is 
> taking a long time
> 15:57:16 systemd[1]: dev-sdb1.device: Job dev-sdb1.device/start timed out.
> 15:57:16 systemd[1]: Timed out waiting for device /dev/sdb1.
> 15:57:16 systemd[1]: Dependency failed for /media/sdb1.
> 15:57:16 systemd[1]: media-sdb1.mount: Job media-sdb1.mount/start failed with 
> result 'dependency'.
> 15:57:16 systemd[1]: Dependency failed for File System Check on /dev/sdb1.
> 15:57:16 systemd[1]: systemd-fsck@dev-sdb1.service: Job 
> systemd-fsck@dev-sdb1.service/start failed with result 'dependency'.
> 15:57:16 systemd[1]: dev-sdb1.device: Job dev-sdb1.device/start failed with 
> result 'timeout'.
> 15:57:16 systemd-udevd[57294]: sdb1: Process '/usr/bin/systemd-mount 
> /dev/sdb1 /media/sdb1' failed with exit code 1.
> ```
> (Removed date and hostname for brevity.)
> 
> While mounting, I had `watch ls /run/systemd/transient/` running, and could 
> see that `media-sdb1.mount` pops into existence immediately when invoking 
> systemd-mount. So whatever tries to access misses it just.
> 
> Following to note:
> * In the example above, systemd-mount got invoked from the following udev 
> rule:
> ```
> ACTION=="add", SUBSYSTEMS=="usb", SUBSYSTEM=="block", KERNEL=="*[0-9]*", 
> ENV{ID_FS_USAGE}=="filesystem", RUN{

Re: [systemd-devel] systemd | Requires statement with an instantiated service

2021-09-02 Thread Andrei Borzenkov
On 02.09.2021 15:10, Leon Fauster wrote:
> On 02.09.21 08:00, Andrei Borzenkov wrote:
>> On 02.09.2021 01:19, Leon Fauster wrote:
>>> Example:
>>>
>>> a@.service
>>> b.service
>>>
>>> a@.service is started as a@host1.service and b.service must be started
>>> after a@host1.service but the unit will be differently parameterized
>>> (depended of the region). So I want to generalize the requires
>>> statement.
>>
>> If you need to manually instantiate a@.service, you can just as well
>> manually add necessary Requires at the same time. E.g.
>>
>> a@.service:
>>
>> [Install]
>> RequiredBy=b.service
>>
>> systemctl enable a@your-region.service
>>
> 
> 
> Indeed that was also what I tried but it seems that my problem is
> that b.service needs a device from a.service, and that seems to need
> some time to come up. Systemd is here to "fast". Just for the sake

It has nothing to do with being fast. Either a@.service should not
complete activation until device became available or you are solving the
wrong problem, because you actually want to order b.service against
device, not some random service.

> of progress I implemented a workaround,
> 
> b.service.d/dep.conf
> [Service]
> ExecStartPre=/bin/sleep 3
> 

I lost you here. If device appears as result of ExecStart in a.service,
no amount of delay *before* ExecStart is going to change anything. If
device appears independently of a.service, you are again solving the
wrong problem.

> a different workaround would be to let b.service fail and with the use
> of Restart=on-failure bring it later up (RestartSec=5) but honestly that
> seems to be more dirty then the above workaround.
> 
> I had also a device.unit in mind as trigger but I can not say in advance
> what device will be used (dev0, dev1, dev2).
> 
> 
> 
...
>>>
>>> I use also a Before=b.service statement for a@.service but that is not
>>> enough.
>>>
>>
>> Why?
> 
> a@.service is started before b.service but in the same second, its to
> close for b.service to be successful.
> 


And how exactly Requires was going to help here?


Re: [systemd-devel] systemd | Requires statement with an instantiated service

2021-09-02 Thread Andrei Borzenkov
On 02.09.2021 01:19, Leon Fauster wrote:
> Dear list,
> 
> following requirement exists here (systemd-239 installed):
> 
> Applying a "Requires" statement with an instantiated service.
> 
> Example:
> 
> a@.service
> b.service
> 
> a@.service is started as a@host1.service and b.service must be started
> after a@host1.service but the unit will be differently parameterized
> (depended of the region). So I want to generalize the requires statement.

If you need to manually instantiate a@.service, you can just as well
manually add necessary Requires at the same time. E.g.

a@.service:

[Install]
RequiredBy=b.service

systemctl enable a@your-region.service

> 
> My dropin file in ./b.service.d/dep.conf looks like
> 
> [Unit]
> Requires="a@*.service"
> 
> This just produces following error:
> 'Failed to add dependency on "a@*.service", ignoring: Invalid argument'
> 
> I use also a Before=b.service statement for a@.service but that is not
> enough.
> 

Why?


Re: [systemd-devel] systemd-udevd: Race condition when rule starts both a systemd-mount and an unit accessing that mount

2021-08-25 Thread Andrei Borzenkov
On Wed, Aug 25, 2021 at 3:44 PM Andrei Borzenkov  wrote:
...
> > Here's the udev rule:
> > ```
> > ACTION=="add", SUBSYSTEMS=="usb", SUBSYSTEM=="block", KERNEL=="*[0-9]*", 
> > ENV{ID_FS_USAGE}=="filesystem", TAG+="systemd", 
> > ENV{SYSTEMD_WANTS}+="start-standalone-mender-deployment@media-$name.service",
> >  RUN{program}+="/usr/bin/systemd-mount --no-block --automount=no 
> > --options=ro --collect $devnode /media/$name"
> > ```
> >
> > And here's the systemd service:
> > It is templated and gets instantiated with "media-sdb1". It therefore has 
> > an "After=media-sdb1.mount". I suspect Systemd-udevd executes the 
> > ENV{SYSTEMD_WANTS} part before the RUN{program} part. Hence, 
> > "media-sdb1.mount" doesn't yet exist when the service gets started, as it 
> > gets created a tad later by systemd-mount.
> >
> > ```
> > [Unit]
> > Description=Start standalone Mender deployment (%i)
> > After=%i.mount
> >
> > [Service]
> > Type=oneshot
> > Restart=no
> > ExecStart=/bin/sh /usr/bin/start-standalone-mender-deployment.sh /%I
> > ```
> >
...
>
> Hmm ... if systemd-mount --property accepts Wants and Before, your
> mount unit could pull in your service unit. I cannot test right now.
>

Yes, this seems to work, so in principle

RUN{program}+="/usr/bin/systemd-mount --no-block --automount=no
--options=ro --collect --property
Wants=start-standalone-mender-deployment@media-$name.service $devnode
/media/$name"

is possible. Unfortunately this starts unit even if mount fails and
systemd-mount does not accept RequiredBy property". It is still
possible to add Requires to service itself.

[Unit]
Description=Start standalone Mender deployment (%i)
After=%i.mount
Requires=%i.mount

This will fail the service start job if the mount job fails.

Wants on mount unit pulls in service, so we are guaranteed to always
have both start jobs - for mount and for service and dependencies are
observed.


Re: [systemd-devel] systemd-udevd: Race condition when rule starts both a systemd-mount and an unit accessing that mount

2021-08-25 Thread Andrei Borzenkov
On Wed, Aug 25, 2021 at 2:26 PM Manuel Wagesreither  wrote:
>
> Hello all,
>
> this is my first post on this mailing list and, first of all, I'd like to 
> thank you and appreciate your work on systemd in general. I admire the logic, 
> the completeness of the manpages and in general how beautifully things are 
> engineered. I'm no unix graybeard and systemd saved me from having to learn 
> all that legacy stuff systemd replaces. Compared to fstab, 
> /etc/network/interfaces and init.d, systemd is a piece of art.
>
> ---
>
> I'm working on an embedded device which should access and scan connected usb 
> drives for certain files. I seem to witness a race condition with my current 
> solution. I would ask for advice on how to implement this functionality in a 
> better way.
>
> When a device /dev/sdb1 is connected, the udev rule below starts BOTH
> * a systemd-service "start-standalone-mender-deployment@media-sdb1.service"
> * `systemd-mount --no-block --automount=no --options=ro --collect /dev/sdb1 
> /media/sdb1`
>
> The service then starts a shell script accessing the usb drive. Occasionally, 
> it says the directory the usb drive is mounted at is empty. When checking 
> manually, I see it's not. I strongly suspect the script accessed the 
> directory before the usb drive got mounted there.
>
> Here's the udev rule:
> ```
> ACTION=="add", SUBSYSTEMS=="usb", SUBSYSTEM=="block", KERNEL=="*[0-9]*", 
> ENV{ID_FS_USAGE}=="filesystem", TAG+="systemd", 
> ENV{SYSTEMD_WANTS}+="start-standalone-mender-deployment@media-$name.service", 
> RUN{program}+="/usr/bin/systemd-mount --no-block --automount=no --options=ro 
> --collect $devnode /media/$name"
> ```
>
> And here's the systemd service:
> It is templated and gets instantiated with "media-sdb1". It therefore has an 
> "After=media-sdb1.mount". I suspect Systemd-udevd executes the 
> ENV{SYSTEMD_WANTS} part before the RUN{program} part. Hence, 
> "media-sdb1.mount" doesn't yet exist when the service gets started, as it 
> gets created a tad later by systemd-mount.
>
> ```
> [Unit]
> Description=Start standalone Mender deployment (%i)
> After=%i.mount
>
> [Service]
> Type=oneshot
> Restart=no
> ExecStart=/bin/sh /usr/bin/start-standalone-mender-deployment.sh /%I
> ```
>
> Can you confirm my theory?
>

This sounds reasonable. Yet again the same confusion - dependencies
are between jobs. "After=%i.mount" actually means "wait until start
job for %i.mount completes before selecting start job for your unit".
If the start job for your unit happens to be selected for execution
before the start job for %i.mount was queued (it is quite possible as
systemd-mount invocation takes time), there is no start job to wait
for and After becomes noop.

> The only alternative I see is to invoke systemd-mount without --no-block from 
> the shell script itself. Instead of communicating the mount point 
> (media-sdb1) via unit template parameter, I would communicate the device path 
> (/dev/sdb1) to the template unit and pass it on to the shell script, which 
> would determine mount point based on that.
>

Yes, there is no nice solution. Systemd was not designed for dynamic
dependencies like in your case. While it is possible to add
Wants=%i.mount to your unit, there is no guarantee that this unit
definition will be present (due to the same race condition).

Sometimes in this case a unit definition file is created and
"systemctl daemon-reload" is invoked. This has its own can of worms so
can hardly be recommended.

So your approach is probably the most practical one.

Hmm ... if systemd-mount --property accepts Wants and Before, your
mount unit could pull in your service unit. I cannot test right now.

> I'm all ears if you have comments or advice on that. I guess I'm not the 
> first one implementing something like this.
>
>
> Regards,
> Manuel
>
> P.S.: I won't be able to respond until Sunday Aug 29th.


Re: [systemd-devel] Can't manage to start a task when bluetooth is ready with systemd

2021-08-16 Thread Andrei Borzenkov
On 16.08.2021 18:20, Gildas Bayard wrote:
> Hello,
> 
> I've first posted on stackoverflow but couldn't get any usefull answer
> (gomenasai )
> 
> I'm trying to start a task when bluetooth is ready on a raspi (running
> raspbian 10 - buster) with systemd. I've added the file
> /etc/systemd/system/my.service with this content
> 
>    |[Unit] After=bluetooth.target Requires=bluetooth.target [Service]
>    Type=idle ExecStart=/root/my.sh [Install] WantedBy=multi-user.target |
> 

This is unreadable.

> Then I used the sudo systemctl enable my.service command, and rebooted.
> 
> After reboot I look at services launch order with |systemd-analyse
> plot|, and it turns out that my service starts after bluetooth.target as
> expected. But bluetooth.target gets started very early (attachment
> bt1.svg). And |systemctl show bluetooth.target| tells me
> 'After=bluetooth.service' so why is bluetooth.target point is reached
> way before bluetooth.service?
> 

Because bluetooth.service is started only if bluetooth devices are
present (ConditionPathIsDirectory=/sys/class/bluetooth). When your
service pulls in bluetooth.target it happens very early, before
bluetooth devices are present, so systemd skips starting of
bluetooth.service. But that is not failure so bluetooth.target is
"started". Later bluetooth.target get start request once more from udev
rule, and this causes second attempt to start bluetooth.service that now
is actually activated.

> I precise that if I use
> 
>    |[Unit] After=bluetooth.service Requires=bluetooth.service|
> 

Would you please apply minimal efforts to write your messages so that
they can be read normally.

> it's also weird: my service is started early, way before
> bluetooth.service and bluetooth.target (which as expected is activated
> rigth after bluetoothd is ready, attachment bt2.svg).
> 
> Could you tell me what's wrong?
> 

Exactly the same. systemd skips starting bluetooth.service early when
your my.service pulls it in. This is not failure, so my.service is
started. Later bluetooth.service gets started by udev rule.

This is the same old fundamental misunderstanding - systemd dependencies
are between jobs, not between units. After=bluetooth.service in
bluetooth.target does not mean bluetooth.target will be activated after
bluetooth.service - it means *start job* for bluetooth.target will be
selected for execution after *start job* for bluetooth.service has
finished. That start job for bluetooth.service did not actually start it
is irrelevant. Start job did not fail so dependent jobs were not cancelled.

Actually this is excellent example how easily systemd dependency system
breaks apart as soon as it hits anything that goes beyond simple "start
these scripts in defined order during system boot". In this case it
trips over conditional start.

The practical solution in your case is to make your service
WantedBy=bluetooth.target and After=bluetooth.service.


Re: [systemd-devel] [EXT] [systemd‑devel] no log information about why machine is sleeping

2021-08-13 Thread Andrei Borzenkov
On 13.08.2021 15:13, George Avrunin wrote:
> On Fri, 13 Aug 2021 08:05:29 +0200, Ulrich Windl wrote:
> 
>>> I suppose that's possible, though I haven't been able to find anywhere
>>> that's configured.  (I'll ask again on the Fedora list to be sure.)  In
>>> the places where I know I've manually configured it (e.g., in the KDE
>>> power settings), it's not supposed to sleep at all when it's on AC
>>> power.   
>>
>> Amazingly in my Leap 15 system it's GNOME that triggers it: If I'm not
>> logged in, no suspend happens, but when I have a GNOME session suspend
>> happens.
> 
> I don't think any actual person was logged in, but gdm was running.  And
> apparently gdm starts gsd-power, the gnome-settings power demon.  I
> haven't yet been able to find where gsd-power gets its settings, but maybe
> it's that, together with treating network activity as "activity" for the
> purposes of deciding when to sleep.  Does anyone here know?
> 

https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/22

> If it was gsd-power that was putting the machine to sleep, it wasn't
> putting anything in the log saying that.
> 



Re: [systemd-devel] no log information about why machine is sleeping

2021-08-11 Thread Andrei Borzenkov
On 12.08.2021 00:11, George Avrunin wrote:
> Hello,
> 
> As a result of a major power outage and consequent issues with some
> switches, my office workstation, a Dell Precision T1700 running
> fully-updated Fedora 34, was off the network for most of last weekend.  As
> our department IT staff detected and fixed the switch issues, they noticed
> that my workstation was putting itself to sleep when it couldn't connect
> to the switch for my floor.  Right now, everything is back up and working,
> but they will probably have to replace the switch.
> 
> However, I haven't been able to figure out why the machine puts itself to
> sleep when it can't reach the switch.  I asked about this on the Fedora
> users list (and included the log entries shown below), and Chris Murphy
> noted that systemd doesn't normally insert the sleep request in the log,
> so it's not possible to determine what caused the sleep request.  He
> suggested that I start a thread here to ask if at least a single line of
> information about how the sleep is being initiated could be dumped into
> the log by default.  
> 
> I will experiment with rebooting with systemd.log_level=debug when I know
> the switch will be shut down for replacement.  But it would be good to get
> more information about what's initiating sleep by default.
> 
> Thanks,
> 
>   George Avrunin
> 
> 
> Here are the relevant log entries from one of the times the machine put
> itself to sleep, apparently because it couldn't connect to the network.
> If there's more information I can supply, please let me know.
> 
> (This starts after power was restored to the building and the machine had
> been manually rebooted just to be sure it would go online.)
> 
> Aug 06 17:47:32 ext.math.umass.edu kernel:
> Lockdown: systemd-logind: hibernation is restricted; see man
> kernel_lockdown.7 Aug 06 17:47:32 ext.math.umass.edu kernel: Lockdown:
> systemd-logind: hibernation is restricted; see man kernel_lockdown.7
> Aug 06 17:47:32 ext.math.umass.edu NetworkManager[2111]: 
> [1628286452.1872] manager: sleep: sleep requested (sleeping: no  enabled:
> yes) Aug 06 17:47:32 ext.math.umass.edu NetworkManager[2111]: 

Anything before these entries? In my case I see

авг 06 08:41:18 bor-Latitude-E5450 systemd-logind[1300]: Lid closed.
авг 06 08:41:18 bor-Latitude-E5450 systemd-logind[1300]: Suspending...
авг 06 08:41:18 bor-Latitude-E5450 kernel: Lockdown: systemd-logind:
hibernation is restricted;
 see man kernel_lockdown.7
авг 06 08:41:18 bor-Latitude-E5450 NetworkManager[1277]: 
[1628228478.4162] manager: sle
ep: sleep requested (sleeping: no  enabled: yes)
...

So here I see the reason for suspend in logs.

> [1628286452.1876] manager: NetworkManager state is now ASLEEP
> Aug 06 17:47:32 ext.math.umass.edu ModemManager[1954]: 
> [sleep-monitor] system is about to suspend
> Aug 06 17:47:32 ext.math.umass.edu gnome-shell[4292]: Screen lock is
> locked down, not locking
> Aug 06 17:47:32 ext.math.umass.edu systemd[1]: Reached target Sleep.
> Aug 06 17:47:32 ext.math.umass.edu systemd[1]: Starting System Suspend...
> Aug 06 17:47:32 ext.math.umass.edu systemd-sleep[40504]: Suspending
> system...
> Aug 06 17:47:32 ext.math.umass.edu kernel: PM: suspend entry (deep)
> Aug 07 14:09:22 ext.math.umass.edu kernel: Filesystems sync: 0.379 seconds
> Aug 07 14:09:22 ext.math.umass.edu kernel: Freezing user space processes
> ... (elapsed 0.002 seconds) done.
> Aug 07 14:09:22 ext.math.umass.edu kernel: OOM killer disabled.
> Aug 07 14:09:22 ext.math.umass.edu kernel: Freezing remaining freezable
> tasks ... (elapsed 0.001 seconds) done.
> Aug 07 14:09:22 ext.math.umass.edu kernel: printk: Suspending console(s)
> (use no_console_suspend to debug)
> Aug 07 14:09:22 ext.math.umass.edu kernel: serial 00:06: disabled
> Aug 07 14:09:22 ext.math.umass.edu kernel: e1000e: EEE TX LPI TIMER:
> 0011
> Aug 07 14:09:22 ext.math.umass.edu kernel: sd 0:0:0:0: [sda] Synchronizing
> SCSI cache
> Aug 07 14:09:22 ext.math.umass.edu kernel: sd 1:0:0:0: [sdb] Synchronizing
> SCSI cache
> Aug 07 14:09:22 ext.math.umass.edu kernel: sd 1:0:0:0: [sdb] Stopping disk
> Aug 07 14:09:22 ext.math.umass.edu kernel: sd 0:0:0:0: [sda] Stopping disk
> Aug 07 14:09:22 ext.math.umass.edu kernel: PM: suspend devices took 1.031
> seconds
> Aug 07 14:09:22 ext.math.umass.edu kernel: ACPI: Preparing to enter system
> sleep state S3
> Aug 07 14:09:22 ext.math.umass.edu kernel: PM: Saving platform NVS memory
> Aug 07 14:09:22 ext.math.umass.edu kernel: Disabling non-boot CPUs ...
> lines 835-871
> etc.
> 



Re: [systemd-devel] Antw: [EXT] Re: Q: "Industry Standard" unit files

2021-08-03 Thread Andrei Borzenkov
On Tue, Aug 3, 2021 at 1:28 PM Ulrich Windl
 wrote:

> Thanks for having a look! So it seems not as broken as I was afraid.
> You are right that the service was written for inetd originally, and one of
> the problems found with systemd is that the process ends with varying exit
> codes (mostly 1 and 3) that systemd considers to be not successful.
>

See SuccessExitStatus in man systemd.service


Re: [systemd-devel] Does systemctl unmask enables a service also?

2021-07-17 Thread Andrei Borzenkov
On 17.07.2021 22:22, Debraj Manna wrote:
> 
> Should not unmasking and starting a service also make it enabled?
> 

No. Starting/stopping, enabling/disabling and masking/unmasking are
orthogonal operations.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Bare Metal or VM

2021-07-16 Thread Andrei Borzenkov
On 17.07.2021 03:36, Ed Greshko wrote:
> Hi,
> 
> This may be an "uninformed" question since I've not done much with systemd.
> 
> Is there a way for a service or unit to be aware if the environment is
> Bare Metal or a Virtual Machine.
> 
> For example, a unit is triggered by a user logging in as a graphical
> user.  But, I only want the unit's
> ExecStart to be processed if the environment is a qemu VM.  I'd rather
> not have the process started on
> Bare Metal since it would be unused.
> 

See ConditionVirtualization directive in man systemd.unit.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Does After=systemd-udevd.service make my service run after the services started by udev rules?

2021-07-13 Thread Andrei Borzenkov
On Tue, Jul 13, 2021 at 4:06 PM Andrei Borzenkov  wrote:
>
> On Tue, Jul 13, 2021 at 3:46 PM Manuel Wagesreither  
> wrote:
> >
> > Hi all,
> >
> > when I have an udev rule with an ENV{SYSTEMD_WANTS}+="my.service", and 
> > another.service with After=systemd-udevd.service, can I at system boot rely 
> > on my.service to be already run when another.service starts?
> >
>
> No. udevd will queue the start job for my.service. It has no relation
> to systemd-udevd.service. If my.service has any ordering dependencies
> that cause it to be delayed, it will be delayed. If it does not have
> extra ordering dependencies, it is not predictable from practical
> point of view when it will be selected for execution. It depends on
> details of internal implementation.
>
> Even if another.service is explicitly ordered After my.service it does
> not really gurantee anything - another.service may have already
> completed when my.service enters queue.
>
> The only way to ensure another.service is always started after
> my.service is to make my.service Want and After another.service and

I meant Wants and Before of course.

> make sure nothing else can cause start job for another.service to be
> queued.
>
>
> > Here's the background to the question:
> >
> > I'm developing an embedded device with autoupdate functionality. It grabs 
> > the new disk image from an usb drive when plugged in. The udev rule and the 
> > systemd units + shell scripts run all fine. The only thing complicating all 
> > this is that at boot into the new system, the udev rule fires as well.
> >
> > I worked around this in the following way:
> > * udev-triggered start-update.service runs only if 
> > /persistent/update-running.stamp doesn't yet exist. When started, it 
> > creates this file.
> > * autoscheduled conclude-update.service contains 
> > After=systemd-udevd.service and removes /persistent/update-running.stamp.
> >
> > I assumed this would at system boot ensure the start-update.service to be 
> > started before conclude-update.service, hence not doing anything. Until 
> > recently, this seemed to worked fine, but I have received reports making me 
> > believe I was just witnessing a race condition resulting in my favor.
> >
> >
> > Best regards,
> > Manuel
> > ___
> > 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] Does After=systemd-udevd.service make my service run after the services started by udev rules?

2021-07-13 Thread Andrei Borzenkov
On Tue, Jul 13, 2021 at 3:46 PM Manuel Wagesreither  wrote:
>
> Hi all,
>
> when I have an udev rule with an ENV{SYSTEMD_WANTS}+="my.service", and 
> another.service with After=systemd-udevd.service, can I at system boot rely 
> on my.service to be already run when another.service starts?
>

No. udevd will queue the start job for my.service. It has no relation
to systemd-udevd.service. If my.service has any ordering dependencies
that cause it to be delayed, it will be delayed. If it does not have
extra ordering dependencies, it is not predictable from practical
point of view when it will be selected for execution. It depends on
details of internal implementation.

Even if another.service is explicitly ordered After my.service it does
not really gurantee anything - another.service may have already
completed when my.service enters queue.

The only way to ensure another.service is always started after
my.service is to make my.service Want and After another.service and
make sure nothing else can cause start job for another.service to be
queued.


> Here's the background to the question:
>
> I'm developing an embedded device with autoupdate functionality. It grabs the 
> new disk image from an usb drive when plugged in. The udev rule and the 
> systemd units + shell scripts run all fine. The only thing complicating all 
> this is that at boot into the new system, the udev rule fires as well.
>
> I worked around this in the following way:
> * udev-triggered start-update.service runs only if 
> /persistent/update-running.stamp doesn't yet exist. When started, it creates 
> this file.
> * autoscheduled conclude-update.service contains After=systemd-udevd.service 
> and removes /persistent/update-running.stamp.
>
> I assumed this would at system boot ensure the start-update.service to be 
> started before conclude-update.service, hence not doing anything. Until 
> recently, this seemed to worked fine, but I have received reports making me 
> believe I was just witnessing a race condition resulting in my favor.
>
>
> Best regards,
> Manuel
> ___
> 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] Expired Message in Log

2021-07-08 Thread Andrei Borzenkov
On 08.07.2021 18:33, Andreas Krueger wrote:
> Hi Folks,
> 
> For my customer I have to verify the logger in its system, which is journald 
> (241). For that I have written some tests that should verify if expired 
> messages will been thrown out of the log. As you can see, the configuration 
> is set in that way that messages older than 12 months shall be removed.
> 
> [Journal]
> Storage=persistent
> Compress=yes
> Seal=yes
> SplitMode=none
> #SyncIntervalSec=5m
> #RateLimitIntervalSec=30s
> #RateLimitBurst=1
> SystemMaxUse=500M
> #SystemKeepFree=
> SystemMaxFileSize=50M
> SystemMaxFiles=13
> #RuntimeMaxUse=
> #RuntimeKeepFree=
> #RuntimeMaxFileSize=
> #RuntimeMaxFiles=100
> MaxRetentionSec=12month
> #MaxFileSec=1month
> #ForwardToSyslog=yes
> #ForwardToKMsg=no
> #ForwardToConsole=no
> #ForwardToWall=yes
> #TTYPath=/dev/console
> #MaxLevelStore=debug
> #MaxLevelSyslog=debug
> #MaxLevelKMsg=notice
> #MaxLevelConsole=info
> #MaxLevelWall=emerg
> #LineMax=48K
> #ReadKMsg=yes
> 
> The test does 5 steps:
> 
>   1.  With the help of command date the system clock is reset by 367 days, 
> which is definitely more than 12 months, even in leap year.

Forward or backward?

>   2.  Send a message to logger.
>   3.  Reset system clock to current time, which was stored before step 1.
>   4.  Send another message to logger.
>   5.  Synchronize the logger, to be sure all data are in the file system.
> 
> What I expect to see is only the message that was sent after resetting the 
> system clock (green text). In fact, I can see the expired message (red text) 
> as well (today is 2021-07-08). Is this correct?
> 

This is plain text mailing list. We do not see any red, green or yellow.

Settings in journald.conf apply to archived journal files only. They do
not apply to active journal file. Was journal rotated in between?

journald does not remove individual "expired" messages, it removes whole
expired journal file. For your message to be removed it must be in
archive file that had been created in the past and which is older than
expiration date. Is it the case?

> Beside this, I have observed, that modifying the time by command date will 
> trigger a rotation. Is this observation correct?

That I cannot answer, but it sounds logical.

> 
> Greeting from Berlin,
> Andreas
> 
> developer@debianVM ../loggerlib/build/integration_test/test 
> (git)-[ak/journal] % journalctl -n 400 --no-pager -o short-iso
> -- Logs begin at Mon 2020-07-06 15:23:50 CEST, end at Thu 2021-07-08 16:23:48 
> CEST. --
> 2021-07-08T15:23:50+0200 debianVM systemd-journald[286]: System journal 
> (/var/log/journal/c1223bdbe6484166aa9af858c392a7e0) is 40.0M, max 500.0M, 
> 460.0M free.
> 2020-07-06T15:23:50+0200 debianVM LoggerLib_sw_integration_test[4941]: 
> Expired Message
> 2021-07-08T15:23:50+0200 debianVM systemd[1]: Starting Rotate log files...
> 2021-07-08T15:23:50+0200 debianVM anacron[4956]: Anacron 2.3 started on 
> 2021-07-08
> 2021-07-08T15:23:50+0200 debianVM systemd[1]: Starting Daily apt download 
> activities...
> 2021-07-08T15:23:50+0200 debianVM anacron[4956]: Normal exit (0 jobs run)
> 2021-07-08T15:23:50+0200 debianVM LoggerLib_sw_integration_test[4941]: Test 
> Message No.0
> 2021-07-08T15:23:50+0200 debianVM systemd[1]: Starting Daily man-db 
> regeneration...
> 2021-07-08T15:23:50+0200 debianVM systemd[1]: Started Run anacron jobs.
> 2021-07-08T15:23:50+0200 debianVM systemd[1]: anacron.service: Succeeded.
> 2021-07-08T15:23:50+0200 debianVM sudo[4940]: pam_unix(sudo:session): session 
> closed for user root
> 2021-07-08T15:23:50+0200 debianVM systemd[1]: logrotate.service: Succeeded.
> 2021-07-08T15:23:50+0200 debianVM systemd[1]: Started Rotate log files.
> 2021-07-08T15:23:50+0200 debianVM systemd[1]: man-db.service: Succeeded.
> 2021-07-08T15:23:50+0200 debianVM systemd[1]: Started Daily man-db 
> regeneration.
> 
> 
> 
> 
> ___
> 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] Reloading configuration after mount unit

2021-06-19 Thread Andrei Borzenkov
On 19.06.2021 11:00, Norbert Lange wrote:
>>
>> What you could try is creating a new unit in /etc/systemd/system/
>> --- systemd-reload.service ---
>> [Unit]
>> Description=Reload systemd
>> Requires=usr-local.mount
>> After=usr-local.mount
>>
>> [Service]
>> Type=oneshot
>> ExecStart=/usr/bin/systemctl --no-block daemon-reload
>>
>> [Install]
>> WantedBy=usr-local.mount
>> ---
>> and than a »systemctl daemon-reload && systemctl enable systemd-
>> reload.service«.
>> In theory (because completly untested) this unit should be activated as
>> soon as your /usr/local mount point is ready.
> 
> Yeah, I did something similar. systemd seems to get the new targets,
> including adding the sysinit.wants symlinks to sysinit.target.
> But doesn't start them.
> 

As already explained systemd builds "transaction" (set of units that are
dependencies of default.target) once on boot and does not reevaluate it.
To start newly available units you need to actually request to start
them. I.e. you would need something like

systemctl --no-block start usr-local.target

where usr-local.target pulls in those units in /usr/local.
usr-local.target can itself be on /usr/local. As you need to configure
your units in /usr/local as dependencies anyway, you can just as well
add them as dependency to usr-local.target instead of sysinit.target.
You can actually have both in case /usr/local will be available early.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Reloading configuration after mount unit

2021-06-18 Thread Andrei Borzenkov
On 18.06.2021 20:48, Norbert Lange wrote:
> Am Fr., 18. Juni 2021 um 16:35 Uhr schrieb Silvio Knizek 
> :
>>
>> Am Freitag, dem 18.06.2021 um 15:04 +0200 schrieb Norbert Lange:
>>> Hello,
>>>
>>> I have an extra mount for /usr/local (Tools + Services which are just
>>> useful for development), classically done vie /etc/fstab.
>>>
>>> Now there are a few systemd services within /usr/local/lib and systemd
>>> does not seem to load/reload those and start the ones that add a
>>> sysinit.wants.
>>>
>>> currently I have to do the following to get a "full start":
>>> systemctl daemon-reload
>>> systemctl start default.target
>>>
>>> What would be the correct way to cause systemd to reevaluate configuration?
>>> I get that this generally could lead to bad behaviour (endless
>>> reconfiguration if cycles),
>>> but for something hierarchical like mount-paths it should be possible.
>>>
>>> I could think of a unit having an after/requires to usr-local.mount or
>>> using a path unit watching PathChanged=/usr/local/lib/systemd.
>>> At any rate, I am not sure how I could tell systemd to start new units
>>> wanted by eg.
>>> sysinit.target if this was already fully started. `systemctl start
>>> default.target` seems
>>> a bit dangerous.
>>>
>>> Another, less important issue is that I cant set lazy unmount in fstab.
>>>
>>> Norbert.
>> Hi Norbert,
>>
>> make sure your /usr/local mount is done in the initrd and that you use
>> »systemctl link /path/to/unit.service« to enable them.
> 
> That's not really helping, I don't want to chug in tons of tools in
> the initramfs this is no desktop system.
> systemctl link shouldnt be necessary, as /usr/local/lib/systemd/system
> is a standard unit path.
> 
> Since there is a systemd-update-done that changes /etc I would have thought 
> that
> systemd rereads the configuration (as /etc/systemd/system could have
> changed) during startup.

The only thing systemd-update-done does is

touch /etc/.updated
touch /var/.updated

It has nothing to do with "rereading configuration".

> I would want that for /usr/local/lib/systemd/system after this path
> was made available through a mount.
> 

systemd will always scan unit path when you attempt to reference unit
not yet loaded. So this "just works".

But you apparently need something different. You want systemd to
retrospectively scan new directory for any unit definition that is
mentioned in any already loaded unit and re-evaluate dependencies.

systemd was never designed for it. It was designed to statically build
full closure of units to be started on boot, and do it just once.

I suppose it is theoretically possible to do it in lazy way - start with
just immediate dependencies of default.target and add dependency of each
unit when you are about to start it. That would do what you want as long
path becomes available before systemd starts units that reference these
path. But that would need radical redesign of the whole dependency chain.

> If systemd assumes the whole /usr drive to be static and has no way to
> dynamically reload and "retarget"
> (adding new wants/requires dependencies to starting/started targets)
> then I guess that's the end of it.
> 

It does not assume anything about /usr, it just builds full set if units
to be started on boot once. Anything not available (visible) at this
moment will not be included in boot "transaction".

> I dont know if thats the case or if I just dont know how (as
> systemd-update-done allows a changing /etc I would assume systemd
> would rescan it for units/dependencies)
> 
>>
>> For the automount behaviour, you need to add
>> »noauto,x-systemd.autmount,x-systemd.idle-timeout=10s«
>> to the options part in the /etc/fstab. See man:systemd.mount for more
>> information.
> 
> Thats Automount, but I want "LazyUnmount",
> and the suggestion kinda contradicts "make sure your /usr/local mount
> is done in the initrd"
> 
> Norbert
> ___
> 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] How to correctly use memory controls (MemoryLow) on unified hierarchy system?

2021-05-21 Thread Andrei Borzenkov
On 21.05.2021 17:07, Benjamin Berg wrote:
> Hi,
> 
> On Fri, 2021-05-21 at 15:25 +0300, Andrei Borzenkov wrote:
>> systemd offers MemoryLow for an individual units. It actually sets
>> memory.low cgroup attribute, so this is OK. The problem is according to
>> kernel dcouemtation, memory.low is limited by value set in parent
>> cgroup and all parent cgroups have memory.low=0:
>>
>> /sys/fs/cgroup/user.slice/user-1001.slice/user@1001.service/gnome-
>> shell-wayland.service/memory.low:536870912
>> /sys/fs/cgroup/user.slice/user-1001.slice/user@1001.service/memory.low:
>> 0
>> /sys/fs/cgroup/user.slice/user-1001.slice/memory.low:0
>> /sys/fs/cgroup/user.slice/memory.low:0
>>
>> which implies setting on lead cgroup has no effect.
>>
>> Is it necessary to explicitly set it on every ancestor? There is no
>> clarification in systemd documentation and value is applied without any
>> warning.
> 
> Yes, you need to set it on all ancestors, and the documentation
> mentions this:
> 
> """
> For a protection to be effective, it is generally required to
> set a corresponding allocation on all ancestors, which is
> then distributed between children (with the exception of the
> root slice). Any MemoryMin= or MemoryLow= allocation that is
> not explicitly distributed to specific children is used to
> create a shared protection for all children. As this is a
> shared protection, the children will freely compete for the
> memory.
> """
> 

OK, it is in upstream now, was not in my version and I did not pay
attention to web page. Sorry.

I guess I expected systemd to somehow handle it, given that it knows all
the settings, knows exact hierarchy and is the sole master of cgroup tree.

> Depending on the kernel versions there may be some other caveats:
> 
> """
> Units may have their children use a default "memory.min" or
> "memory.low" value by specifying DefaultMemoryMin= or
> DefaultMemoryLow=, which has the same semantics as MemoryMin=
> and MemoryLow=. This setting does not affect "memory.min" or
> "memory.low" in the unit itself. Using it to set a default
> child allocation is only useful on kernels older than 5.7,
> which do not support the "memory_recursiveprot" cgroup2 mount
> option.
> """
> 
> You need to configure it correctly in various locations. Personally, I
> would suggest taking a look at uresourced[1]. It will correctly set a
> configurable memory protection, enables some other cgroup features and
> tracks the currently active user. Fedora is shipping it by default and
> it appears to work well there.
> 

That's overkill for my purposes. This is single user system and all I am
trying to do is to prevent swapping out Wayland composer to avoid
waiting several minutes to unblank screen. I am fine with setting values
once.

Thanks for the pointers.

> Benjamin
> 
> [1] https://gitlab.freedesktop.org/benzea/uresourced and
> https://lwn.net/Articles/829567/
> 

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


Re: [systemd-devel] depending on user units

2021-05-21 Thread Andrei Borzenkov
On 21.05.2021 18:18, lejeczek wrote:
> Hi guys.
> 
> While surfing the web for answers I thought I would try to call on
> experts - how, if possible at all, to make systemd service unit depend
> on users' unit/services?
> 

No, it is not possible. Nor is it really possible in reverse direction.
systemd "imports" some specific units (devices and mounts) from system
space into each user space, but that's all.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] How to correctly use memory controls (MemoryLow) on unified hierarchy system?

2021-05-21 Thread Andrei Borzenkov
systemd offers MemoryLow for an individual units. It actually sets
memory.low cgroup attribute, so this is OK. The problem is according to
kernel dcouemtation, memory.low is limited by value set in parent cgroup
and all parent cgroups have memory.low=0:

/sys/fs/cgroup/user.slice/user-1001.slice/user@1001.service/gnome-shell-wayland.service/memory.low:536870912
/sys/fs/cgroup/user.slice/user-1001.slice/user@1001.service/memory.low:0
/sys/fs/cgroup/user.slice/user-1001.slice/memory.low:0
/sys/fs/cgroup/user.slice/memory.low:0

which implies setting on lead cgroup has no effect.

Is it necessary to explicitly set it on every ancestor? There is no
clarification in systemd documentation and value is applied without any
warning.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Need help to debug TAG-= rule

2021-05-16 Thread Andrei Borzenkov
On 16.05.2021 14:07, Manuel Reimer wrote:
> Hello systemd-devel list,
> 
> 
> according to the changelog of udev, it should be possible to clear TAGs
> using "TAG-=" since systemd 217:
> 
> https://cgit.freedesktop.org/systemd/systemd/tree/NEWS?id=v217#n70
> 
> But either I'm completely failing with using this, or there is still a
> bug in systemd which renders this feature useless.
> 
> 
> My distributor installs a udev rule file at
> "/usr/lib/udev/rules.d/70-steam-input.rules" which contains:
> 
>     KERNEL=="uinput", SUBSYSTEM=="misc", OPTIONS+="static_node=uinput",
> TAG+="uaccess", OPTIONS+="static_node=uinput"
> 
> (don't ask why the OPTIONS+= is duplicated but that's what my
> distributor installs)
> 
> 
> I want to get rid of the 'TAG+="uaccess"' on my system but want to keep
> all the other rules in this file without copying and editing it after
> every update. So I created the folllowing as
> "/etc/udev/rules.d/72-steam-security.rules":
> 
> KERNEL=="uinput", SUBSYSTEM=="misc", TAG-="uaccess"
> 
> 
> But after rebooting my system I still have:
> 
> $ getfacl /dev/uinput
> getfacl: Removing leading '/' from absolute path names
> # file: dev/uinput
> # owner: root
> # group: root
> user::rw-
> user:manuel:rw-
> group::---
> mask::rw-
> other::---
> 
> So I still get write access to the device which I don't want to have
> 
> 
> I don't know at all how to dig into this. A first try was to use
> "udevadm test /devices/virtual/misc/uinput" but this doesn't even
> mention the "70-steam-input.rules" file.
> 

Is uinput module loaded at this point?

> I did try to just rename "70-steam-input.rules" to be sure it is
> responsible for the "uaccess" tag to be set and it is. If the file is
> renamed, then I no longer get unwanted write permissions.
> 
> 
> Can someone please assist with finding the reason for this problem?
> 


udev commits option static_node using whatever settings for
user/group/tag are ON THE SAME LINE. It does not matter that you remove
tag later - udev already saw and processed

OPTIONS+="static_nodes=uinput", TAG+="uaccess"

and created /run/udev/static_node-tags/uaccess/uinput. It is not removed
when tag is removed.

Static nodes are processed literally line based - udev iterates over
each line. It is not obvious how to fix it - static nodes exist *before*
any device node appears, so you basically does not have anything to
attach permissions to.

udev tries to assign static node the same permissions as it would have
got on uevent, but instead of looking at final permissions it looks only
for one line.

This is src/udev/udev-rules.c:udev_rules_apply_static_dev_perms()

You should open issue on github so it can be tracked. Current
implementation is certainly questionable.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


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


  1   2   3   4   5   6   7   8   >