Re: [systemd-devel] [question] is it possible with systemd-journalctl to change the location to save logs in other location?

2020-08-16 Thread ionut n
 

Pe duminică, 16 august 2020, 20:00:10 EEST, Lennart Poettering 
 a scris:  
 
 On So, 16.08.20 16:35, ionut n (ionut_n2...@yahoo.com) wrote:

>
> Hi SystemD Team,
>
> One question.
>
> Is it possible with systemd-journalctl to change the location to save logs in 
> other location?
>
> My system is volatile (tmpfs) and I have another location available to keep 
> certain logs.
>
>    - /dev/root or / is tmpfs
>    - /external-persistent0 is ext4 or xfs
>
> I would like to save the logs here:
> /external-persistent0/journal
>
> Is it possible to do this?
> In the current documentation for journalctl I have not seen anything about 
> this.
> Thank you and have a good day to the whole team.

Use bind mounts or symlinks.

In systemd we think it's important that the same resources are
available under the same path as much as possible. Where that path
ultimately points to (by means of symlinks or bind mounts) doesn't
matter to us much, we just think it's much simpler if the paths stay
fixed and are useful universal identifiers, even if the stuff behind
them is actually placed somehere else.

Lennart

--
Lennart Poettering, Berlin


I understand, but there is no option or any parameter in systemd to not do 
through mount?
Is there no other solution?





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


Re: [systemd-devel] [question] is it possible with systemd-journalctl to change the location to save logs in other location?

2020-08-16 Thread ionut n
 I understand, but there is no option or any parameter in systemd  to not do 
through mount?
Pe duminică, 16 august 2020, 19:48:51 EEST, Tomasz Torcz 
 a scris:  
 
 On Sun, Aug 16, 2020 at 04:35:48PM +, ionut n wrote:
> 
> Hi SystemD Team,

  It's "systemd" (all lowercase).

> 
> One question.
> 
> Is it possible with systemd-journalctl to change the location to save logs in 
> other location?
> 
> My system is volatile (tmpfs) and I have another location available to keep 
> certain logs.
>    
>    - /dev/root or / is tmpfs
>    - /external-persistent0 is ext4 or xfs
> 
> I would like to save the logs here:
> /external-persistent0/journal
> 
> Is it possible to do this?
> In the current documentation for journalctl I have not seen anything about 
> this.

  Journal stores persistent logs in /var/log/journal, so best course of
action would be to mount --bind /external-persistent0/journal /var/log/journal
A symlink from /var/log/journal to /external-persistent0/journal may
work, too.

-- 
Tomasz Torcz                        To co nierealne – tutaj jest normalne.
to...@pipebreaker.pl              Ziomale na życie mają tu patenty specjalne.

___
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] [question] is it possible with systemd-journalctl to change the location to save logs in other location?

2020-08-16 Thread Lennart Poettering
On So, 16.08.20 16:35, ionut n (ionut_n2...@yahoo.com) wrote:

>
> Hi SystemD Team,
>
> One question.
>
> Is it possible with systemd-journalctl to change the location to save logs in 
> other location?
>
> My system is volatile (tmpfs) and I have another location available to keep 
> certain logs.
>
>- /dev/root or / is tmpfs
>- /external-persistent0 is ext4 or xfs
>
> I would like to save the logs here:
> /external-persistent0/journal
>
> Is it possible to do this?
> In the current documentation for journalctl I have not seen anything about 
> this.
> Thank you and have a good day to the whole team.

Use bind mounts or symlinks.

In systemd we think it's important that the same resources are
available under the same path as much as possible. Where that path
ultimately points to (by means of symlinks or bind mounts) doesn't
matter to us much, we just think it's much simpler if the paths stay
fixed and are useful universal identifiers, even if the stuff behind
them is actually placed somehere else.

Lennart

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


Re: [systemd-devel] [question] is it possible with systemd-journalctl to change the location to save logs in other location?

2020-08-16 Thread Tomasz Torcz
On Sun, Aug 16, 2020 at 04:35:48PM +, ionut n wrote:
> 
> Hi SystemD Team,

  It's "systemd" (all lowercase).

> 
> One question.
> 
> Is it possible with systemd-journalctl to change the location to save logs in 
> other location?
> 
> My system is volatile (tmpfs) and I have another location available to keep 
> certain logs.
>
>- /dev/root or / is tmpfs
>- /external-persistent0 is ext4 or xfs
> 
> I would like to save the logs here:
> /external-persistent0/journal
> 
> Is it possible to do this?
> In the current documentation for journalctl I have not seen anything about 
> this.

  Journal stores persistent logs in /var/log/journal, so best course of
action would be to mount --bind /external-persistent0/journal /var/log/journal
A symlink from /var/log/journal to /external-persistent0/journal may
work, too.

-- 
Tomasz TorczTo co nierealne – tutaj jest normalne.
to...@pipebreaker.pl  Ziomale na życie mają tu patenty specjalne.

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


Re: [systemd-devel] question about a poweroff issue

2020-03-31 Thread Lennart Poettering
On Mi, 26.02.20 13:50, piliu (pi...@redhat.com) wrote:

> Hi,
>
> I encountered a systemd bug during saving vmcore for kdump kernel.
>
> I got the following message:
>
> [   60.283489] systemd[1]: Started Reload Configuration from the Real Root.
> [   60.290912] systemd[1]: Reached target Initrd File Systems.
> [   60.296162] systemd[1]: Reached target Initrd Default Target.
> [   60.299343] systemd[1]: Starting dracut pre-pivot and cleanup hook...
>  Starting dracut pre-pivot and cleanup hook...
> [  OK  ] Started dracut pre-pivot and cleanup hook.
> [   60.338320] systemd[1]: Started dracut pre-pivot and cleanup hook.
> [   60.340503] systemd[1]: Starting Kdump Vmcore Save Service...
>  Starting Kdump Vmcore Save Service...
> kdump: dump target /dev/mapper/rhel_storageqe--25-root is not mounted,
> trying to mount...
> kdump: saving to
> /sysroot//mnt/kdump_multi/var/crash/127.0.0.1-2020-02-20-05:00:45/
> kdump: saving vmcore-dmesg.txt
> kdump: saving vmcore-dmesg.txt complete
> kdump: saving vmcore
> Copying data  : [100.0 %] /
>  eta: 0s
> kdump: saving vmcore complete
> Bus n/a: changing state UNSET → OPENING
> Bus n/a: changing state OPENING → AUTHENTICATING
> Bus n/a: changing state AUTHENTICATING → RUNNING
> Sent message type=method_call sender=n/a
> destination=org.freedesktop.systemd1 path=/org/freedesktop/systemd1
> interface=org.freedesktop.systemd1.Manager member=Reboot cookie=1
> reply_cookie=0 signature=n/a error-name=n/a error-message=n/a
> [   66.032946] systemd[1]: Shutting down.
> Got message type=method_return sender=org.freedesktop.systemd1
> destination=n/a path=n/a interface=n/a member=n/a cookie=1
> reply_cookie=1 signature=n/a error-name=n/a error-message=n/a
> Bus n/a: changing state RUNNING → CLOSED
> [   66.060777] printk: systemd-shutdow: 350 output lines suppressed due
> to ratelimiting
> [   66.316784] printk: systemd-journal: 13 output lines suppressed due
> to ratelimiting
> [  156.506161] qla2xxx [:08:00.1]-fffa:1: Adapter shutdown
> [  156.535660] qla2xxx [:08:00.1]-00af:1: Performing ISP error
> recovery - ha=350c9f53.
> [  156.581142] qla2xxx [:08:00.1]-fffe:1: Adapter shutdown successfully.
> [  156.612816] qla2xxx [:08:00.0]-fffa:0: Adapter shutdown
> [  156.638997] qla2xxx [:08:00.0]-00af:0: Performing ISP error
> recovery - ha=7acbb643.
> [  156.681032] qla2xxx [:08:00.0]-fffe:0: Adapter shutdown successfully.
>
>
> In the kdump script, for the final step, it calls "systemctl reboot -f".
> But it seems the system is experiencing poweroff instead of reboot.

Pass "printk.devkmsg=on" so that you can actually see the debug output
of systemd-shutdown. It might tell you what is going on.

> Further more, in kdump script, even if I placed "sleep 60" before
> "systemctl reboot -f", the extra command did not take effect, and the
> system just start to poweroff immediately. So I guess there is another
> process to launch the poweroff action, but how to know what is it?

Enable debug logging, and use "printk.devkmsg=on", then you should be
able to figure out what is going on.

https://freedesktop.org/wiki/Software/systemd/Debugging/#index2h1

Lennart

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


Re: [systemd-devel] Question on Before=

2019-02-02 Thread Steve Dickson


On 2/2/19 3:44 PM, Reindl Harald wrote:
> 
> 
> Am 02.02.19 um 21:05 schrieb Steve Dickson:
>> On 2/2/19 2:52 PM, Reindl Harald wrote:
>>> Am 02.02.19 um 20:42 schrieb Steve Dickson:
 Hello,

 In a.service  I have 

 [Unit]
 Before=b.service 

 [Install]
 RequiredBy=b.service

 when I systemd start b.service (which happens to fail) 
 but... a.service is not being run.

 So I guess my question is what do I have to do
 to ensure a.service is *always* run before b.service?
>>>
 [Install]
 RequiredBy=b.service
>>>
>>> why?
>>>
>>> [Unit]
>>> Before/After/Require
>>>
>>> [Install]
>>> WantedBy=multi-user.target
>> Because a.service only needs to run when b.service is started. 
> 
> this is a cirrcualr dependency!
> 
> you say "start a before b" and at the same time "start a only when b is
> started"
> 
> hwo do you imagine that to work?
> 
That a would start before b because of the Before= in a.

There was an issue as how I was enabling a... 

thanks for the help!

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


Re: [systemd-devel] Question on Before=

2019-02-02 Thread Steve Dickson


On 2/2/19 4:03 PM, Tomasz Torcz wrote:
> On Sat, Feb 02, 2019 at 03:03:22PM -0500, Steve Dickson wrote:
>>
>>
>> On 2/2/19 2:48 PM, Tomasz Torcz wrote:
>>> On Sat, Feb 02, 2019 at 02:42:15PM -0500, Steve Dickson wrote:
 Hello,

 In a.service  I have 

 [Unit]
 Before=b.service 

 [Install]
 RequiredBy=b.service

 when I systemd start b.service (which happens to fail) 
 but... a.service is not being run.

 So I guess my question is what do I have to do
 to ensure a.service is *always* run before b.service?
>>>
>>>   Have you enabled a.service?
>>>
>> No... I did not think I had to... I figured 
>> when b.service was started, a.service would be 
>> run regardless of being enabled or disabled.
>>
>> Is that not the case?
> 
>   Not really.  It would work, if you had in b.service line like
> Requires=a.service (*).
>   But apparently you do not want to modify b.service, so you
> put RequiredBy= in a.service's [Install] section. Directives
> in [Install] section requires "systemctl enable" to have symlinks
> created and to have effect. After enable, it will work identical to (*).
> 
>   Nb. most services have RequireBy=multi-user.target (or WantedBy=). For
> such services, enabling mean they will start at boot (beacuse
> multi-user.target is part of boot process).  But there is not
> requirement for services to be Wanted/Required by not boot-related
> services and target.
>   Thus, you often find in tutorials assertion that 
> "systemctl enable" equals "start during boot". This is not true.
It turns out I had a bug in my spec file logic which should
have enabled the service... 

Thanks for the help!

steved.

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


Re: [systemd-devel] Question on Before=

2019-02-02 Thread Steve Dickson


On 2/2/19 4:07 PM, Uoti Urpala wrote:
> On Sat, 2019-02-02 at 15:03 -0500, Steve Dickson wrote:
>>>   Have you enabled a.service?
>>>
>> No... I did not think I had to... I figured 
>> when b.service was started, a.service would be 
>> run regardless of being enabled or disabled.
>>
>> Is that not the case?
> 
> So you just have the file for a.service lying somewhere on disk, but
> haven't enabled it and no other unit references it? 
That is true... 

> That won't do anything - systemd does not read through all files on disk to 
> see if
> there'd be something inside the file which declares that it should
> actually be started. Units need to have something else referencing them
> for systemd to "see" them at all. "enable" does this by creating a link
> from the units/targets referenced in the [Install] section to the file
> in question (by creating a symlink in 
> /etc/systemd/system/multi-user.target.wants/ for example).
Basically enabling the service... fair enough... 

steved.

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


Re: [systemd-devel] Question on Before=

2019-02-02 Thread Tomasz Torcz
On Sat, Feb 02, 2019 at 03:03:22PM -0500, Steve Dickson wrote:
> 
> 
> On 2/2/19 2:48 PM, Tomasz Torcz wrote:
> > On Sat, Feb 02, 2019 at 02:42:15PM -0500, Steve Dickson wrote:
> >> Hello,
> >>
> >> In a.service  I have 
> >>
> >> [Unit]
> >> Before=b.service 
> >>
> >> [Install]
> >> RequiredBy=b.service
> >>
> >> when I systemd start b.service (which happens to fail) 
> >> but... a.service is not being run.
> >>
> >> So I guess my question is what do I have to do
> >> to ensure a.service is *always* run before b.service?
> > 
> >   Have you enabled a.service?
> > 
> No... I did not think I had to... I figured 
> when b.service was started, a.service would be 
> run regardless of being enabled or disabled.
> 
> Is that not the case?

  Not really.  It would work, if you had in b.service line like
Requires=a.service (*).
  But apparently you do not want to modify b.service, so you
put RequiredBy= in a.service's [Install] section. Directives
in [Install] section requires "systemctl enable" to have symlinks
created and to have effect. After enable, it will work identical to (*).

  Nb. most services have RequireBy=multi-user.target (or WantedBy=). For
such services, enabling mean they will start at boot (beacuse
multi-user.target is part of boot process).  But there is not
requirement for services to be Wanted/Required by not boot-related
services and target.
  Thus, you often find in tutorials assertion that 
"systemctl enable" equals "start during boot". This is not true.


-- 
Tomasz Torcz"Funeral in the morning, IDE hacking
xmpp: zdzich...@chrome.plin the afternoon and evening." - Alan Cox

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


Re: [systemd-devel] Question on Before=

2019-02-02 Thread Uoti Urpala
On Sat, 2019-02-02 at 15:03 -0500, Steve Dickson wrote:
> >   Have you enabled a.service?
> > 
> No... I did not think I had to... I figured 
> when b.service was started, a.service would be 
> run regardless of being enabled or disabled.
> 
> Is that not the case?

So you just have the file for a.service lying somewhere on disk, but
haven't enabled it and no other unit references it? That won't do
anything - systemd does not read through all files on disk to see if
there'd be something inside the file which declares that it should
actually be started. Units need to have something else referencing them
for systemd to "see" them at all. "enable" does this by creating a link
from the units/targets referenced in the [Install] section to the file
in question (by creating a symlink in 
/etc/systemd/system/multi-user.target.wants/ for example).


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


Re: [systemd-devel] Question on Before=

2019-02-02 Thread Reindl Harald


Am 02.02.19 um 21:05 schrieb Steve Dickson:
> On 2/2/19 2:52 PM, Reindl Harald wrote:
>> Am 02.02.19 um 20:42 schrieb Steve Dickson:
>>> Hello,
>>>
>>> In a.service  I have 
>>>
>>> [Unit]
>>> Before=b.service 
>>>
>>> [Install]
>>> RequiredBy=b.service
>>>
>>> when I systemd start b.service (which happens to fail) 
>>> but... a.service is not being run.
>>>
>>> So I guess my question is what do I have to do
>>> to ensure a.service is *always* run before b.service?
>>
>>> [Install]
>>> RequiredBy=b.service
>>
>> why?
>>
>> [Unit]
>> Before/After/Require
>>
>> [Install]
>> WantedBy=multi-user.target
> Because a.service only needs to run when b.service is started. 

this is a cirrcualr dependency!

you say "start a before b" and at the same time "start a only when b is
started"

hwo do you imagine that to work?

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


Re: [systemd-devel] Question on Before=

2019-02-02 Thread Reindl Harald


Am 02.02.19 um 21:03 schrieb Steve Dickson:
> On 2/2/19 2:48 PM, Tomasz Torcz wrote:
>> On Sat, Feb 02, 2019 at 02:42:15PM -0500, Steve Dickson wrote:
>>> Hello,
>>>
>>> In a.service  I have 
>>>
>>> [Unit]
>>> Before=b.service 
>>>
>>> [Install]
>>> RequiredBy=b.service
>>>
>>> when I systemd start b.service (which happens to fail) 
>>> but... a.service is not being run.
>>>
>>> So I guess my question is what do I have to do
>>> to ensure a.service is *always* run before b.service?
>>
>>   Have you enabled a.service?
>>
> No... I did not think I had to... I figured 
> when b.service was started, a.service would be 
> run regardless of being enabled or disabled.
> 
> Is that not the case?

that's not how it works


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


Re: [systemd-devel] Question on Before=

2019-02-02 Thread Steve Dickson


On 2/2/19 2:52 PM, Reindl Harald wrote:
> 
> 
> Am 02.02.19 um 20:42 schrieb Steve Dickson:
>> Hello,
>>
>> In a.service  I have 
>>
>> [Unit]
>> Before=b.service 
>>
>> [Install]
>> RequiredBy=b.service
>>
>> when I systemd start b.service (which happens to fail) 
>> but... a.service is not being run.
>>
>> So I guess my question is what do I have to do
>> to ensure a.service is *always* run before b.service?
> 
>> [Install]
>> RequiredBy=b.service
> 
> why?
> 
> [Unit]
> Before/After/Require
> 
> [Install]
> WantedBy=multi-user.target
Because a.service only needs to run when b.service is started. 

steved.

> ___
> 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] Question on Before=

2019-02-02 Thread Steve Dickson


On 2/2/19 2:48 PM, Tomasz Torcz wrote:
> On Sat, Feb 02, 2019 at 02:42:15PM -0500, Steve Dickson wrote:
>> Hello,
>>
>> In a.service  I have 
>>
>> [Unit]
>> Before=b.service 
>>
>> [Install]
>> RequiredBy=b.service
>>
>> when I systemd start b.service (which happens to fail) 
>> but... a.service is not being run.
>>
>> So I guess my question is what do I have to do
>> to ensure a.service is *always* run before b.service?
> 
>   Have you enabled a.service?
> 
No... I did not think I had to... I figured 
when b.service was started, a.service would be 
run regardless of being enabled or disabled.

Is that not the case?

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


Re: [systemd-devel] Question on Before=

2019-02-02 Thread Tomasz Torcz
On Sat, Feb 02, 2019 at 02:42:15PM -0500, Steve Dickson wrote:
> Hello,
> 
> In a.service  I have 
> 
> [Unit]
> Before=b.service 
> 
> [Install]
> RequiredBy=b.service
> 
> when I systemd start b.service (which happens to fail) 
> but... a.service is not being run.
> 
> So I guess my question is what do I have to do
> to ensure a.service is *always* run before b.service?

  Have you enabled a.service?

-- 
Tomasz Torcz"Funeral in the morning, IDE hacking
xmpp: zdzich...@chrome.plin the afternoon and evening." - Alan Cox

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


Re: [systemd-devel] Question on Before=

2019-02-02 Thread Reindl Harald


Am 02.02.19 um 20:42 schrieb Steve Dickson:
> Hello,
> 
> In a.service  I have 
> 
> [Unit]
> Before=b.service 
> 
> [Install]
> RequiredBy=b.service
> 
> when I systemd start b.service (which happens to fail) 
> but... a.service is not being run.
> 
> So I guess my question is what do I have to do
> to ensure a.service is *always* run before b.service?

> [Install]
> RequiredBy=b.service

why?

[Unit]
Before/After/Require

[Install]
WantedBy=multi-user.target
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Question about WATCHDOG

2019-01-11 Thread Dave Reisner
On Fri, Jan 11, 2019 at 08:03:45AM +, Sietse van Zanen wrote:
> Hi,
> 
>  
> 
> I am writing a daemon script which uses sd_notify watchdog. This works fine,
> system will kill the if the process doesn’t notify.
> 
>  
> 
> However, I have seen in 1 occasion where, due to a programming error, the
> script got stuck in a read and was not killed where it should have been.
> 
> So my question is, what does systemd actually do when the watchdog expires,
> which signal does it send?
> 

It's well documented in the manpages. From systemd.service(5) under the
description of WatchdogSec=:

  If the time between two such calls is larger than the configured time,
  then the service is placed in a failed state and it will be terminated
  with SIGABRT (or the signal specified by WatchdogSignal=)

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


Re: [systemd-devel] Question about hardware watchdog

2018-11-05 Thread Lennart Poettering
On Mo, 05.11.18 16:21, Liu, Shuang (ADITG/ESM) (s...@de.adit-jv.com) wrote:

> Hi,
> 
> We are facing problem with hardware watchdog.
> 
> To my understanding, the watchdog is pinged inside the manager_loop(),
> which means, during e.g. systemctl daemon-reload, watchdog cannot be pinged.
> 
> Here, perhaps other timeouts are involved in, e.g. generator timeout, dbus 
> timeout, systemctl timeout, ...
> which could be larger than the RuntimeWatchdogSec.
> 
> Thus a problem with systemctl daemon-reload could trigger the watchdog 
> timeout.

Yes, and that's intended. If an event is dispatched (such as a reload
request) and we don't return to normal event loop processing within
the watchdog timeout, then the watchdog will react and reboot. 

Lennart

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


Re: [systemd-devel] Question about the default value of NamePolicy=

2018-08-02 Thread Francis Moreau
Hello,

On Wed, Aug 1, 2018 at 7:36 PM, Mantas Mikulėnas  wrote:
>
> AFAIK, "onboard" and (hotplug) "slot" names are mutually exclusive, so their
> relative ordering isn't that important... but if the firmware marks a device
> as on-board *and* also provides a slot number, then it's more likely that
> the slot# is garbage.
>

Thanks for the info.

> Both "onboard" and "slot" are preferred over "path" because they're shorter
> and more descriptive (as long as the firmware provides correct values). The
> path, being based on PCI bus addressing, doesn't say much to most people --
> at best, it's just a stable identifier. (For example, my server's integrated
> NIC port #1 is better named "eno1", not "enp3s0f0".)
>

"path" can also run onto problem when adapters are replaced by new
ones with multiple ports for example.

Would "onboard" or "slot" be a better alternative for such case ?

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


Re: [systemd-devel] Question about the default value of NamePolicy=

2018-08-01 Thread Mantas Mikulėnas
On Wed, Aug 1, 2018 at 7:18 PM Francis Moreau 
wrote:

> Hello,
>
> I have a question regarding the default value of NamePolicy= defined
> in 99-default.link.
>
> The value is "NamePolicy=kernel database onboard slot path"
>
> Could someone explain me why "onbard" is preferred over "slot" which
> is preferred over "path" ?
>

AFAIK, "onboard" and (hotplug) "slot" names are mutually exclusive, so
their relative ordering isn't that important... but if the firmware marks a
device as on-board *and* also provides a slot number, then it's more likely
that the slot# is garbage.

Both "onboard" and "slot" are preferred over "path" because they're shorter
and more descriptive (as long as the firmware provides correct values). The
path, being based on PCI bus addressing, doesn't say much to most people --
at best, it's just a stable identifier. (For example, my server's
integrated NIC port #1 is better named "eno1", not "enp3s0f0".)

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


Re: [systemd-devel] question about Wants and unit start-up order

2018-03-24 Thread Mantas Mikulėnas
On Sat, Mar 24, 2018 at 5:54 PM, Brian J. Murrell 
wrote:

> On Sat, 2018-03-24 at 17:39 +0200, Mantas Mikulėnas wrote:
> >
> > Which systemd version do you run? In v232,
>
> systemd-219-42.el7_4.10.x86_64
>
> > nss-lookup.target:Description=Host and Network Name Lookups
> > nss-user-lookup.target:Description=User and Group Name Lookups
>
> Same here:
>
> # systemctl show nss-lookup.target | grep Description
> Description=Host and Network Name Lookups
> # systemctl show nss-user-lookup.target | grep Description
> Description=User and Group Name Lookups
>
> For my purposes, it is "Host and Network Name Lookups" that I am
> looking to gate other things on but that target needs to wait for named
> to be up before it is considered reached, which does not seem to be
> happening here.
>

But your log snippet is talking about nss-user-lookup.target.

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


Re: [systemd-devel] question about Wants and unit start-up order

2018-03-24 Thread Brian J. Murrell
On Sat, 2018-03-24 at 17:39 +0200, Mantas Mikulėnas wrote:
> 
> Which systemd version do you run? In v232,

systemd-219-42.el7_4.10.x86_64

> nss-lookup.target:Description=Host and Network Name Lookups
> nss-user-lookup.target:Description=User and Group Name Lookups

Same here:

# systemctl show nss-lookup.target | grep Description
Description=Host and Network Name Lookups
# systemctl show nss-user-lookup.target | grep Description
Description=User and Group Name Lookups

For my purposes, it is "Host and Network Name Lookups" that I am
looking to gate other things on but that target needs to wait for named
to be up before it is considered reached, which does not seem to be
happening here.

Cheers,
b.

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


Re: [systemd-devel] question about Wants and unit start-up order

2018-03-24 Thread Mantas Mikulėnas
On Fri, Mar 23, 2018 at 9:52 PM, Brian J. Murrell 
wrote:

> On Fri, 2018-03-23 at 21:45 +0200, Mantas Mikulėnas wrote:
> >
> > No, dependencies do not imply any specific ordering. (The only
> > exception is
> > when a .target wants/requires another unit.)
>
> That seems odd but I will leave that aside for a moment...
>
> > In other words, you will need to additionally list the same units in
> > After=, or in certain cases in Before=. (For example, named is a nss-
> > lookup
> > provider, so it should have "Before=nss-lookup.target", but
> > "After=named-setup-mdc.service".)
>
> That is the case:
>
> # systemctl show named-pkcs11.service | grep -ie ^before -e ^after
> Before=nss-lookup.target shutdown.target
> After=system.slice named-setup-rndc.service tmp.mount -.mount var.mount
> network.target systemd-journald.socket basic.target named-dhcp.service
>
> So it's still puzzling why they report out of order in the journal.
>
> > On another note, Wants=system.slice is *very* redundant – all system
> > services go into that slice anyway.
>
> That was output from systemctl show so it was probbaby just reflecting
> that, as the one above does.
>

Which systemd version do you run? In v232,

nss-lookup.target:Description=Host and Network Name Lookups
nss-user-lookup.target:Description=User and Group Name Lookups

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


Re: [systemd-devel] question about Wants and unit start-up order

2018-03-24 Thread Brian J. Murrell
On Fri, 2018-03-23 at 21:45 +0200, Mantas Mikulėnas wrote:
> 
> No, dependencies do not imply any specific ordering. (The only
> exception is
> when a .target wants/requires another unit.)

That seems odd but I will leave that aside for a moment...

> In other words, you will need to additionally list the same units in
> After=, or in certain cases in Before=. (For example, named is a nss-
> lookup
> provider, so it should have "Before=nss-lookup.target", but
> "After=named-setup-mdc.service".)

That is the case:

# systemctl show named-pkcs11.service | grep -ie ^before -e ^after
Before=nss-lookup.target shutdown.target
After=system.slice named-setup-rndc.service tmp.mount -.mount var.mount 
network.target systemd-journald.socket basic.target named-dhcp.service

So it's still puzzling why they report out of order in the journal.

> On another note, Wants=system.slice is *very* redundant – all system
> services go into that slice anyway.

That was output from systemctl show so it was probbaby just reflecting
that, as the one above does.

Cheers,
b.


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] question about Wants and unit start-up order

2018-03-23 Thread Mantas Mikulėnas
On Fri, Mar 23, 2018 at 5:41 PM, Brian J. Murrell 
wrote:

> If I have:
>
> Wants=system.slice nss-lookup.target named-setup-rndc.service
>
> in named-pkcs11.service, so shouldn't mean that named-pkcs11.service
> will be started up before the nss-lookup.target is Reached/Started?
>

No, dependencies do not imply any specific ordering. (The only exception is
when a .target wants/requires another unit.)

In other words, you will need to additionally list the same units in
After=, or in certain cases in Before=. (For example, named is a nss-lookup
provider, so it should have "Before=nss-lookup.target", but
"After=named-setup-mdc.service".)

On another note, Wants=system.slice is *very* redundant – all system
services go into that slice anyway.

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


Re: [systemd-devel] Question about a random UDP port on rpcbind 0.2.3 started by systemd

2018-01-26 Thread Jérémy Rosen


if you have the mentionned file (/usr/lib/systemd/system/rpcbind.socket) 
then systemd will open whatever port is described in there and pass it 
pre-opened to rpcbind.


systemd has no idea what that port is for and the file mentionned above 
was provided to systemd by the rpcbind package. You should really ask 
the rpcbind people what it is for, systemd is just the messenger here...


On 26/01/2018 03:48, Bao Nguyen wrote:

Hello evryone,

I would like to ask you a question regarding the new random UDP port in
rpcbind 0.2.3.

In rpcbind 0.2.3, when I start rpcbind (version 0.2.3) through
rpcbind.service, then I do netstat

udp0  0 0.0.0.0:111 0.0.0.0:*
  10408/rpcbind
udp0  0 0.0.0.0:831 0.0.0.0:*
  10408/rpcbind
udp6   0  0 :::111  :::*
 10408/rpcbind
udp6   0  0 :::831  :::*
 10408/rpcbind

The rpcbind does not only listen on port 111 but also on a random udp port
"831" in this case, this port is changed every time the rpcbind service
retstarts. And it listens on 0.0.0.0 so it opens a hole on security.

I have looked into the change of rpcbind 0.2.3 and found the change "
rpcbind: add support for systemd socket activation", it calls a
function sd_listen_fds, I do not know much about systemd socket activation
programming, does the "831" port is generated from rpcbind to communicate
with systemd socket activation?

Could you please let me know what this port is for and is there any way to
avoid that like force it listen on a internal interface rather than on any
interfaces like that? As the rpcbind is started from systemd so "-h" option
is invalid as the man page says:


-h  Specify specific IP addresses to bind to for UDP requests.  This
option may be specified multiple times and can be used to restrict the
interfaces rpcbind will respond to.  Note that when rpcbind is controlled
via sys-
  temd's socket activation, the -h option is ignored. In this
case, you need to edit the ListenStream and ListenDgram definitions in
/usr/lib/systemd/system/rpcbind.socket instead.



Thanks a lot,
Brs,
Bao



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


--
SMILE 

20 rue des Jardins
92600 Asnières-sur-Seine


*Jérémy ROSEN*
Architecte technique
Responsable de l'expertise Smile-ECS

email jeremy.ro...@smile.fr 
phone +33141402967
url http://www.smile.eu

Twitter  Facebook 
 LinkedIn 
 Github 




Découvrez l’univers Smile, rendez-vous sur smile.eu 



eco Pour la planète, n'imprimez ce mail que si c'est nécessaire
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] question about socket activation

2018-01-24 Thread Lennart Poettering
On Fr, 29.12.17 17:19, eshark (eshar...@163.com) wrote:

> Hi, All
>   I tried to test the socket activation by a simple foobar.socket and 
> foobar.service, which are as the following:
>   foobar.socket: 
>[Socket]
>ListenStream=/dev/socket/foobar
> 
> 
>[Install]
>WantedBy=sockets.target 
> 
> 
>   foobar.service: 
>[Service]
>Type=simple
>ExecStart=/usr/bin/test-socket
>   Restart=no
> 
> 
>  I also wrote a simple program to connect to /dev/socket/foobar , in 
> order to activitate the foobar.service.
> When I ran the program,  the foobar.service  was started by systemd , and 
> the foobar.socket changed from 'listening' state to 'running' state. 
>  All works OK as expected,  but  when I killed the  test-socket,  it was 
> started again by the systemd, even if I didn't run my program.
> And from the system journal logs , I found  that
> "
> Line 2035: 31,29604,571630004,-;systemd[1]: foobar.socket got notified about 
> service death (failed permanently: no)
> Line 2038: 31,29605,571630065,-;systemd[1]: foobar.socket changed running -> 
> listening
> Line 2050: 31,29609,571632385,-;systemd[1]: Incoming traffic on foobar.socket
> Line 2056: 28,29611,571633087,-;systemd[1]: Cannot add dependency job for 
> unit systemd-bus-proxyd.socket, ignoring: Unit systemd-bus-proxyd.socket 
> failed to load: No such file or directory.
> Line 2056: 28,29611,571633087,-;systemd[1]: Cannot add dependency job for 
> unit systemd-bus-proxyd.socket, ignoring: Unit systemd-bus-proxyd.socket 
> failed to load: No such file or directory.
> Line 2065: 31,29614,571633544,-;systemd[1]: foobar.socket changed listening 
> -> running   
> "
>  It seems that immediately after the death of foobar.service,some unknown 
> incoming traffic  on foobar.socket   made the foobar.service started again by 
> the systemd .
>   Could anyone give me some suggestion that  who connected to the 
> foobar.socket  ?   Any idea about how to debug this problem  is very 
> appreciated.

If your service is activated due to incoming traffic and you do not
process the incoming traffic and exit, then you will be started
immediately again, as the socket still has traffic queued.

The idea is usually to process everything queued up on the listening
socket, and then exit until the next incoming traffic.

If you never accept any of the incoming connections you hence will
make systemd busy loop around your service.

Lennart

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


Re: [systemd-devel] question about socket activation

2018-01-01 Thread eshark
The program source codes and the foobar.service , the foobar.socket are as the 
attachments.


Thanks for any suggestion! 






At 2017-12-29 16:19:35, "eshark"  wrote:

Hi, All
  I tried to test the socket activation by a simple foobar.socket and 
foobar.service, which are as the following:
  foobar.socket: 
   [Socket]
   ListenStream=/dev/socket/foobar


   [Install]
   WantedBy=sockets.target 


  foobar.service: 
   [Service]
   Type=simple
   ExecStart=/usr/bin/test-socket
  Restart=no


 I also wrote a simple program to connect to /dev/socket/foobar , in order 
to activitate the foobar.service.
When I ran the program,  the foobar.service  was started by systemd , and 
the foobar.socket changed from 'listening' state to 'running' state. 
 All works OK as expected,  but  when I killed the  test-socket,  it was 
started again by the systemd, even if I didn't run my program.
And from the system journal logs , I found  that
"
Line 2035: 31,29604,571630004,-;systemd[1]: foobar.socket got notified about 
service death (failed permanently: no)
Line 2038: 31,29605,571630065,-;systemd[1]: foobar.socket changed running -> 
listening
Line 2050: 31,29609,571632385,-;systemd[1]: Incoming traffic on foobar.socket
Line 2056: 28,29611,571633087,-;systemd[1]: Cannot add dependency job for unit 
systemd-bus-proxyd.socket, ignoring: Unit systemd-bus-proxyd.socket failed to 
load: No such file or directory.
Line 2056: 28,29611,571633087,-;systemd[1]: Cannot add dependency job for unit 
systemd-bus-proxyd.socket, ignoring: Unit systemd-bus-proxyd.socket failed to 
load: No such file or directory.
Line 2065: 31,29614,571633544,-;systemd[1]: foobar.socket changed listening -> 
running   
"
 It seems that immediately after the death of foobar.service,some unknown 
incoming traffic  on foobar.socket   made the foobar.service started again by 
the systemd .
  Could anyone give me some suggestion that  who connected to the foobar.socket 
 ?   Any idea about how to debug this problem  is very appreciated.


 Thanks a lot.




 #include 
#include 
#include 
#include 
#include 
#define UNIX_DOMAIN "/dev/socket/foobar"

#define CONTAINER_EXIT_PROP_NAME "sys.pagemanagerd.status"
#define HOST_EXIT_PROP_NAME "service.bootanim.exit"



int require_services(void)
{
int connect_fd;
int ret;
int i;
static struct sockaddr_un srv_addr;

connect_fd=socket(PF_UNIX,SOCK_STREAM,0);
if(connect_fd<0)
{
perror("cannot create communication socket");
return 1;
}
srv_addr.sun_family=AF_UNIX;
strcpy(srv_addr.sun_path,UNIX_DOMAIN);
ret=connect(connect_fd,(struct sockaddr*)_addr,sizeof(srv_addr));
if(ret==-1)
{
perror("cannot connect to the server");
close(connect_fd);
return 0;
}
close(connect_fd);
return 0;
}

int main(void)
{
   require_services();
   sleep(10);
   return 0;
}


foobar.service
Description: Binary data


foobar.socket
Description: Binary data
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [QUESTION] AIX 7.1 nodes area not reporting

2017-11-29 Thread Mantas Mikulėnas
On Thu, Nov 30, 2017 at 7:19 AM, Vengatesh R 
wrote:

> Hi Team,
>
>
>
> AIX 7.1 nodes area not reporting to puppet master. Please find the below
> details.
>
>
>
> Puppet master : Red hat Linux 7.3 x86_64
>

Hi,

this is not the Puppet mailing list, not the AIX mailing list, and not the
Red Hat support mailing list.

(And there were no details to be found, either.)

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


Re: [systemd-devel] Question about service dependency handling in systemd-228

2017-11-29 Thread Bao Nguyen
Hi all,

Thank you very much for your support.

I will try to fix the cycle.

Brs,

On Mon, Nov 27, 2017 at 4:11 PM, Reindl Harald 
wrote:

>
>
> Am 27.11.2017 um 05:23 schrieb Bao Nguyen:
>
>> Thanks all for your comments. I will try to use option FreeBind. However
>> could anyone explain for me that I did not use FreeBind option in
>> systems-210 but all my services start well? I am still inclined to the
>> different of systemd-228 and systemd-210 causes the current issue.
>>
>
> beause your configuration was undefined behavior and never made any sense
> when there are dependency loops and similar problems - systemd does and did
> the best not throw you to the mergency console and boot the system somehow,
> pointed out errors and now it's time to fi them
>
> IMHO it would be justified not to boot at all if there is as example a
> unit which has itself in After/Before/Requires as example when someone
> don't read his systemlogs after change units and "systemctl daemon-reload"
> :-)
>
>
> On Sun, Nov 26, 2017 at 4:53 PM, Reindl Harald > > wrote:
>>
>>
>>
>> Am 26.11.2017 um 10:47 schrieb Bao Nguyen:
>>
>> Regard to your question, "asi-My-5101.socket" depends on
>> "My-sshd.target", I think that in my case it is expected as my
>> socket listens on a specific address IP:port so it should start
>> after a network service to configure and assign IP address
>> before my socket runs
>>
>>
>> nonsense - the whole point of socket activation is to have sockets
>> listening before other stuff is up and running
>>
>> https://www.freedesktop.org/software/systemd/man/systemd.socket.html
>> > >
>> If an IP address is used here, it is often desirable to listen on it
>> before the interface it is configured on is up and running, and even
>> regardless of whether it will be up and running at any point. To
>> deal with this, it is recommended to set the FreeBind= option
>> described below
>>
>> FreeBind=
>> Takes a boolean value. Controls whether the socket can be bound to
>> non-local IP addresses. This is useful to configure sockets
>> listening on specific IP addresses before those IP addresses are
>> successfully configured on a network interface. This sets the
>> IP_FREEBIND socket option. For robustness reasons it is recommended
>> to use this option whenever you bind a socket to a specific IP
>> address. Defaults to false.
>>
> ___
> 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] [Question]: About systemctl and its related commands

2017-11-28 Thread 千葉幹正
Thank you.

I know have a deeper understanding of the this topic :)

Regards.
Chiba

2017年11月28日(火) 23:32 Lennart Poettering :

> f1;5002;0cOn Di, 28.11.17 16:16, 千葉幹正 (chib...@klab.com) wrote:
>
> > We have a few questions about systemctl and -H option.
> >
> > It looks like systemctl is communicating with /run/systemd/private in
> order
> > to interact with systemd.
> >
> > However, after you log in the connected computer via ssh, it looks like
> > it's trying to control systemd by going through systemd-stdio-bridge when
> > you use systemctl's -H option.
> >
> > Instead of going through /run/systemd/private, it looks like
> > systemd-stdio-bridge is going through /run/dbus/system_bus_socket (which
> is
> > usually created by dbus daemon) in order to control systemd.
> >
> > This where we run into the following 2 questions:
> >
> > 1. Is it necessary to start up dbus daemon on the computer we're
> connecting
> > to in order to control systemd by using the systemctl -H option?
>
> Currently, yes. And I doubt this will change anytime soon.
>
> D-Bus is designed around a bus concept: all services are available on
> the same IPC bus. That's usually a good thing, as that means systemctl
> can talk to all services it needs to through a single IPC
> connection. systemctl talks to a number of daemons actually, not just
> PID 1: for example, it also talks to logind and policykit.
>
> If the private IPC socket is used a very limited way of IPC is
> available only: since the other side is PID 1 and PID 1 only, there's
> no hookup with polkit, and communication with logind is not
> available. Moreover a couple of peer tracking concepts in PID 1 are
> disabled for such "direct" connections, as a peer concept is not
> really existing for such connections that do not involve a bus.
>
> systemctl currently contains some logic to use the private socket
> (i.e. a direct connection) automatically in a number of cases,
> preferring it over the bus. It does that so that systemctl can talk to
> systemd during early boot too (when dbus-daemon is not up yet, hence
> the proper bus is not available), as well as when the system is really
> hosed (so that you can still debug things and shut things down). The
> direct connections however are a very specific hack in systemctl
> ultimately, done under very specific conditions, in order to deal with
> a very specific set of problems. When PK or logind involvement is
> needed, when the caller is not privileged and so on, the direct
> connections are not used. Now, the ssh transport (i.e. -H) doesn't
> know about all this, and cannot possibly guess what systemctl actually
> wants to do, hence it is exclusively a gateway to the full bus, it
> contains no special hookup with the private socket. Moreover, ssh is
> a late boot service anyway, i.e. dbus is already up at that moment,
> hence the early-boot reason for the private socket doesn't even apply
> to remote connections at all..
>
> > 2. Are we correct in our understanding that /run/systemd/private exists
> to
> > control systemctl though the local systemd?
>
> the private socket is an implementation detail between systemctl and
> systemd, to support the aforementioned usecases. It's not a public
> API (which is the reason btw, why it is called 'private'…), it's not
> fully featured, and it should not be used except under very well
> defined conditions, and remote access does not fall under that.
>
> > Why does systemctl use the specialized interface called
> > /run/systemd/private to control systemd?
> > Why doesn't systemd-stdio-bridge control systemd via /run/systemd/private
> > like systemctl does?
>
> Besides the fact that systemctl talks to logind and so on, the stdio
> bridge is also used by the various other tools in systemd, including
> machinectl, loginctl, busctl, systemd-run, … Since they generally talk
> to other daemons than just PID 1 a full ybus connection is required.
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
>
-- 
KLab株式会社 インフラマネジメント部
千葉 幹正 chib...@klab.com

 [東京本社]
  〒106-6122 東京都港区六本木6-10-1 六本木ヒルズ森タワー22F
  TEL:03-5771-1818  / FAX:03-3403-8520
 [地方・海外拠点]
仙台/大阪/福岡/シンガポール/上海
 [弊社HP]
  http://www.klab.com/jp/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [Question]: About systemctl and its related commands

2017-11-28 Thread Lennart Poettering
f1;5002;0cOn Di, 28.11.17 16:16, 千葉幹正 (chib...@klab.com) wrote:

> We have a few questions about systemctl and -H option.
> 
> It looks like systemctl is communicating with /run/systemd/private in order
> to interact with systemd.
> 
> However, after you log in the connected computer via ssh, it looks like
> it's trying to control systemd by going through systemd-stdio-bridge when
> you use systemctl's -H option.
> 
> Instead of going through /run/systemd/private, it looks like
> systemd-stdio-bridge is going through /run/dbus/system_bus_socket (which is
> usually created by dbus daemon) in order to control systemd.
> 
> This where we run into the following 2 questions:
> 
> 1. Is it necessary to start up dbus daemon on the computer we're connecting
> to in order to control systemd by using the systemctl -H option?

Currently, yes. And I doubt this will change anytime soon.

D-Bus is designed around a bus concept: all services are available on
the same IPC bus. That's usually a good thing, as that means systemctl
can talk to all services it needs to through a single IPC
connection. systemctl talks to a number of daemons actually, not just
PID 1: for example, it also talks to logind and policykit.

If the private IPC socket is used a very limited way of IPC is
available only: since the other side is PID 1 and PID 1 only, there's
no hookup with polkit, and communication with logind is not
available. Moreover a couple of peer tracking concepts in PID 1 are
disabled for such "direct" connections, as a peer concept is not
really existing for such connections that do not involve a bus.

systemctl currently contains some logic to use the private socket
(i.e. a direct connection) automatically in a number of cases,
preferring it over the bus. It does that so that systemctl can talk to
systemd during early boot too (when dbus-daemon is not up yet, hence
the proper bus is not available), as well as when the system is really
hosed (so that you can still debug things and shut things down). The
direct connections however are a very specific hack in systemctl
ultimately, done under very specific conditions, in order to deal with
a very specific set of problems. When PK or logind involvement is
needed, when the caller is not privileged and so on, the direct
connections are not used. Now, the ssh transport (i.e. -H) doesn't
know about all this, and cannot possibly guess what systemctl actually
wants to do, hence it is exclusively a gateway to the full bus, it
contains no special hookup with the private socket. Moreover, ssh is
a late boot service anyway, i.e. dbus is already up at that moment,
hence the early-boot reason for the private socket doesn't even apply
to remote connections at all..

> 2. Are we correct in our understanding that /run/systemd/private exists to
> control systemctl though the local systemd?

the private socket is an implementation detail between systemctl and
systemd, to support the aforementioned usecases. It's not a public
API (which is the reason btw, why it is called 'private'…), it's not
fully featured, and it should not be used except under very well
defined conditions, and remote access does not fall under that.

> Why does systemctl use the specialized interface called
> /run/systemd/private to control systemd?
> Why doesn't systemd-stdio-bridge control systemd via /run/systemd/private
> like systemctl does?

Besides the fact that systemctl talks to logind and so on, the stdio
bridge is also used by the various other tools in systemd, including
machinectl, loginctl, busctl, systemd-run, … Since they generally talk
to other daemons than just PID 1 a full ybus connection is required.

Lennart

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


Re: [systemd-devel] [Question]: About systemctl and its related commands

2017-11-28 Thread aleivag
Hi, i asked similar question a few weeks ago, and you probably will get a
oficial answer soon :P, but in a nutshell would be:

/run/systemd/private is a private socket and its meant for systemd tools to
communicate with systemd even if dbus daemon is down. this is specially
true during boot and shutdown, but you should never try to use the private
sockets for anything, always use dbus sockets, because (in Lennard's words,
not mine) "systemd sucks as a bus replacement". if posible, even forget
that /run/systemd/private exists :P.

after playing around a lot with servers i agree with previous statements,
and always prefere dbus over private.

hope that helps.


Alvaro

On Mon, Nov 27, 2017 at 11:16 PM, 千葉幹正  wrote:

> We have a few questions about systemctl and -H option.
>
> It looks like systemctl is communicating with /run/systemd/private in
> order to interact with systemd.
>
> However, after you log in the connected computer via ssh, it looks like
> it's trying to control systemd by going through systemd-stdio-bridge when
> you use systemctl's -H option.
>
> Instead of going through /run/systemd/private, it looks like
> systemd-stdio-bridge is going through /run/dbus/system_bus_socket (which is
> usually created by dbus daemon) in order to control systemd.
>
> This where we run into the following 2 questions:
>
> 1. Is it necessary to start up dbus daemon on the computer we're
> connecting to in order to control systemd by using the systemctl -H option?
>
> 2. Are we correct in our understanding that /run/systemd/private exists to
> control systemctl though the local systemd?
>
> Why does systemctl use the specialized interface called
> /run/systemd/private to control systemd?
> Why doesn't systemd-stdio-bridge control systemd via /run/systemd/private
> like systemctl does?
>
> Any information you can provide about the above would be much appreciated!
> Thanks in advance for your time and all your help.
>
> All the best,
>
> Chiba
> KLab Inc.
>
> ___
> 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] Question

2017-11-27 Thread Lennart Poettering
On Sa, 25.11.17 15:24, Peter Diks (peterd...@gmail.com) wrote:

> Hello Systemd-devel@lists.freedesktop.org,
> 
> There is something i do not understand at this point and would like to
> solve it.
> A brand new Tumbleweed Kubic, has enable repositories and zypper runs fine,
> untill it has to install.
> Error: Subprocess failed. Error: RPM failed: error: Can 't create
> transaction lock on /var/lib/.rpm.lock ( inappropriate ioctl for device )
> Earlier i had the same sort of trouble: installing on a read-only fs.
> A mount -o remount,rw / does not change that ( although i'm root )
> So i can 't run Zypper up.

Sorry, but this is not a systemd-related question. Please ping the
SUSE tumbleweed community instead. Thanks.

Lennart

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


Re: [systemd-devel] Question about service dependency handling in systemd-228

2017-11-27 Thread Reindl Harald



Am 27.11.2017 um 05:23 schrieb Bao Nguyen:
Thanks all for your comments. I will try to use option FreeBind. However 
could anyone explain for me that I did not use FreeBind option in 
systems-210 but all my services start well? I am still inclined to the 
different of systemd-228 and systemd-210 causes the current issue.


beause your configuration was undefined behavior and never made any 
sense when there are dependency loops and similar problems - systemd 
does and did the best not throw you to the mergency console and boot the 
system somehow, pointed out errors and now it's time to fi them


IMHO it would be justified not to boot at all if there is as example a 
unit which has itself in After/Before/Requires as example when someone 
don't read his systemlogs after change units and "systemctl 
daemon-reload" :-)


On Sun, Nov 26, 2017 at 4:53 PM, Reindl Harald > wrote:




Am 26.11.2017 um 10:47 schrieb Bao Nguyen:

Regard to your question, "asi-My-5101.socket" depends on
"My-sshd.target", I think that in my case it is expected as my
socket listens on a specific address IP:port so it should start
after a network service to configure and assign IP address
before my socket runs


nonsense - the whole point of socket activation is to have sockets
listening before other stuff is up and running

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

If an IP address is used here, it is often desirable to listen on it
before the interface it is configured on is up and running, and even
regardless of whether it will be up and running at any point. To
deal with this, it is recommended to set the FreeBind= option
described below

FreeBind=
Takes a boolean value. Controls whether the socket can be bound to
non-local IP addresses. This is useful to configure sockets
listening on specific IP addresses before those IP addresses are
successfully configured on a network interface. This sets the
IP_FREEBIND socket option. For robustness reasons it is recommended
to use this option whenever you bind a socket to a specific IP
address. Defaults to false.

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


Re: [systemd-devel] Question about service dependency handling in systemd-228

2017-11-26 Thread Bao Nguyen
Hi,

Thanks all for your comments. I will try to use option FreeBind. However
could anyone explain for me that I did not use FreeBind option in
systems-210 but all my services start well? I am still inclined to the
different of systemd-228 and systemd-210 causes the current issue.

Thanks again,
Brs,
Bao



On Sun, Nov 26, 2017 at 4:53 PM, Reindl Harald 
wrote:

>
>
> Am 26.11.2017 um 10:47 schrieb Bao Nguyen:
>
>> Regard to your question, "asi-My-5101.socket" depends on
>> "My-sshd.target", I think that in my case it is expected as my socket
>> listens on a specific address IP:port so it should start after a network
>> service to configure and assign IP address before my socket runs
>>
>
> nonsense - the whole point of socket activation is to have sockets
> listening before other stuff is up and running
>
> https://www.freedesktop.org/software/systemd/man/systemd.socket.html
> If an IP address is used here, it is often desirable to listen on it
> before the interface it is configured on is up and running, and even
> regardless of whether it will be up and running at any point. To deal with
> this, it is recommended to set the FreeBind= option described below
>
> FreeBind=
> Takes a boolean value. Controls whether the socket can be bound to
> non-local IP addresses. This is useful to configure sockets listening on
> specific IP addresses before those IP addresses are successfully configured
> on a network interface. This sets the IP_FREEBIND socket option. For
> robustness reasons it is recommended to use this option whenever you bind a
> socket to a specific IP address. Defaults to false.
>
> ___
> 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] Question about service dependency handling in systemd-228

2017-11-26 Thread Mantas Mikulėnas
On Sun, Nov 26, 2017 at 11:47 AM, Bao Nguyen  wrote:

> Hi Uoti,
>
> Thanks a lot for your answer, I have checked the cycle. It is created by 
> sockets.target
> -> asi-My-5101.socket -> My-sshd.target -> My-syncd.service -> 
> My-nfs-client.service
> -> My-handling.service -> basic.target -> sockets.target. I do not see
> the same cycle in systemd-210 so I said that there is maybe a change in
> systemd-210 and sytemd-228 like building dependency tree and handling
> cycle. I can confirm there is no change in my scripts.
>

Could you please show the full (not paraphrased) dependencies that you
have? that is, [Unit] sections, *.wants/ contents, and such


>
> Regard to your question, "asi-My-5101.socket" depends on
> "My-sshd.target", I think that in my case it is expected as my socket
> listens on a specific address IP:port so it should start after a network
> service to configure and assign IP address before my socket runs.
>

"My-sshd.target" does not sound like a network service.

In any case, just use FreeBind=true instead.

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


Re: [systemd-devel] Question about service dependency handling in systemd-228

2017-11-26 Thread Reindl Harald



Am 26.11.2017 um 10:47 schrieb Bao Nguyen:
Regard to your question, "asi-My-5101.socket" depends on 
"My-sshd.target", I think that in my case it is expected as my socket 
listens on a specific address IP:port so it should start after a network 
service to configure and assign IP address before my socket runs


nonsense - the whole point of socket activation is to have sockets 
listening before other stuff is up and running


https://www.freedesktop.org/software/systemd/man/systemd.socket.html
If an IP address is used here, it is often desirable to listen on it 
before the interface it is configured on is up and running, and even 
regardless of whether it will be up and running at any point. To deal 
with this, it is recommended to set the FreeBind= option described below


FreeBind=
Takes a boolean value. Controls whether the socket can be bound to 
non-local IP addresses. This is useful to configure sockets listening on 
specific IP addresses before those IP addresses are successfully 
configured on a network interface. This sets the IP_FREEBIND socket 
option. For robustness reasons it is recommended to use this option 
whenever you bind a socket to a specific IP address. Defaults to false.

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


Re: [systemd-devel] Question about service dependency handling in systemd-228

2017-11-26 Thread Bao Nguyen
Hi Uoti,

Thanks a lot for your answer, I have checked the cycle. It is created
by sockets.target
-> asi-My-5101.socket -> My-sshd.target -> My-syncd.service ->
My-nfs-client.service
-> My-handling.service -> basic.target -> sockets.target. I do not see the
same cycle in systemd-210 so I said that there is maybe a change in
systemd-210 and sytemd-228 like building dependency tree and handling
cycle. I can confirm there is no change in my scripts.

Regard to your question, "asi-My-5101.socket" depends on "My-sshd.target",
I think that in my case it is expected as my socket listens on a specific
address IP:port so it should start after a network service to configure and
assign IP address before my socket runs.

Could you please help me if it is due to the fault in sytemd-228 or I have
to adapt my script to overcome this issue? I tried to
add DefaultDependencies=no in my asi-My-5101.socket, the problem go away
(because sometimes I see it said the cycle created in basic.target, the
behavior is really strange in systemd-228).

Thanks,
Brs,
Bao

On Sat, Nov 25, 2017 at 9:44 PM, Uoti Urpala 
wrote:

> On Sat, 2017-11-25 at 12:08 +0700, Bao Nguyen wrote:
> > [   41.154231] systemd[1]: nss-lookup.target: Dependency
> Before=nss-lookup.target dropped
> > [   41.297229] systemd[1]: sockets.target: Found ordering cycle on
> sockets.target/start
> > [   41.297236] systemd[1]: sockets.target: Found dependency on
> asi-My-5101.socket/start
> > [   41.297239] systemd[1]: sockets.target: Found dependency on
> My-sshd.target/start
> > [   41.297241] systemd[1]: sockets.target: Found dependency on
> My-syncd.service/start
> > [   41.297244] systemd[1]: sockets.target: Found dependency on
> My-nfs-client.service/start
> > [   41.297246] systemd[1]: sockets.target: Found dependency on
> My-handling.service/start
>
>
> > My question is if there are any significant different about building
> tree dependency and handling cycle dependency between systemd-210 and
> systemd-228 that can lead to my current situation? I have checked the
> change log, source code but not found any useful info
>
> Rather than start by trying to find differences between systemd
> versions, I suggest you first find out exactly what goes wrong under
> the newer systemd version. Exactly which dependency is wrong and
> shouldn't be there? Where does that dependency come from? A system
> where ordering dependencies form a cycle is not valid, so some
> dependency explicitly listed in your unit files or implicitly added by
> systemd must be wrong. After finding that out, you can then try to find
> out what differs under the older systemd if it's still relevant.
>
> In the above log, the most suspicious part is that it seems to say
> "asi-My-5101.socket" depends on "My-sshd.target". A socket unit almost
> certainly shouldn't have such dependencies, as normally a listening
> socket can be opened regardless of the state of the rest of the system
> (the main exception I can think of would be a UNIX socket at a
> filesystem path that requires mounting something, but normally you
> wouldn't do that...).
>
>
> > And what does the message "nss-lookup.target: Dependency
> Before=nss-lookup.target dropped" mean? I do not see it in systemd-210.
>
> Apparently the target had a dependency saying that it should be started
> before itself, and such a blatantly impossible dependency was ignored.
>
> ___
> 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] Question

2017-11-25 Thread Reindl Harald



Am 25.11.2017 um 16:24 schrieb Peter Diks:
Hello Systemd-devel@lists.freedesktop.org 
,


There is something i do not understand at this point and would like to 
solve it.
A brand new Tumbleweed Kubic, has enable repositories and zypper runs 
fine, untill it has to install.
Error: Subprocess failed. Error: RPM failed: error: Can 't create 
transaction lock on /var/lib/.rpm.lock ( inappropriate ioctl for device )

Earlier i had the same sort of trouble: installing on a read-only fs.
A mount -o remount,rw / does not change that ( although i'm root )
So i can 't run Zypper up


how is that a systemd-question?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Question about service dependency handling in systemd-228

2017-11-25 Thread Uoti Urpala
On Sat, 2017-11-25 at 12:08 +0700, Bao Nguyen wrote:
> [   41.154231] systemd[1]: nss-lookup.target: Dependency 
> Before=nss-lookup.target dropped
> [   41.297229] systemd[1]: sockets.target: Found ordering cycle on 
> sockets.target/start
> [   41.297236] systemd[1]: sockets.target: Found dependency on 
> asi-My-5101.socket/start
> [   41.297239] systemd[1]: sockets.target: Found dependency on 
> My-sshd.target/start
> [   41.297241] systemd[1]: sockets.target: Found dependency on 
> My-syncd.service/start
> [   41.297244] systemd[1]: sockets.target: Found dependency on 
> My-nfs-client.service/start
> [   41.297246] systemd[1]: sockets.target: Found dependency on 
> My-handling.service/start


> My question is if there are any significant different about building tree 
> dependency and handling cycle dependency between systemd-210 and systemd-228 
> that can lead to my current situation? I have checked the change log, source 
> code but not found any useful info

Rather than start by trying to find differences between systemd
versions, I suggest you first find out exactly what goes wrong under
the newer systemd version. Exactly which dependency is wrong and
shouldn't be there? Where does that dependency come from? A system
where ordering dependencies form a cycle is not valid, so some
dependency explicitly listed in your unit files or implicitly added by
systemd must be wrong. After finding that out, you can then try to find
out what differs under the older systemd if it's still relevant.

In the above log, the most suspicious part is that it seems to say
"asi-My-5101.socket" depends on "My-sshd.target". A socket unit almost
certainly shouldn't have such dependencies, as normally a listening
socket can be opened regardless of the state of the rest of the system
(the main exception I can think of would be a UNIX socket at a
filesystem path that requires mounting something, but normally you
wouldn't do that...).


> And what does the message "nss-lookup.target: Dependency 
> Before=nss-lookup.target dropped" mean? I do not see it in systemd-210.

Apparently the target had a dependency saying that it should be started
before itself, and such a blatantly impossible dependency was ignored.

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


Re: [systemd-devel] Question: path-based deactivation or equivalent

2017-09-27 Thread Lennart Poettering
On Di, 26.09.17 16:15, matt...@giassa.net (matt...@giassa.net) wrote:

>   I have a project where I'm adding some services to a Raspberry Pi 3,
> and have decided to go with systemd being (mostly) responsible for
> launching all of the services. All of the server processes use a common
> API to do some initial setup (argument parsing, init, etc), drop root
> permissions, and then carry out their normal duties. One of these
> services is the "master" service, which I want to use to
> activate/deactivate other services on-demand.
> 
>   I started out with path-based activation via systemd, and that
> worked fine for bringing up the services as I requested them.  However,
> it seems there is no equivalent path-based deactivation functionality at
> this time [1], so it's definitely not an option on the older OS deployed
> on my dev board.

Unit deactivation triggered by fs events has been requested before
(there's a github RFE issue about it somewhere), but I am not
convinced this is a good idea, and the semantics aren't clear about it
at all.

First of all, the states of .path units and the units they trigger are
actually connected: as long as the service a .path is supposed to
trigger is running the .path unit is in a "dormant" mode, and won't
care for any fs events, until the service is terminated again, at
which point the state is rechecked and things might trigger
again. This scheme is not compatible with .path based deactivation
really...

The other thing is: i fail to see the usecase. Things like PathExists=
and DirectoryNotEmpty= have a clear usecase where they aren't racy:
they trigger a service that processes files that are created somewhere
and delete the files when they are done with them. As long as there
are files there, the service will be restarted. And the service is
supposed to exit when it's done.

Now, if you want to use .path just a communication protocol: there are
way better ways to solve that. use systemctl, or use the D-Bus
API. File system objects are not a great replacement for an IPC.

Lennart

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


Re: [systemd-devel] Question: path-based deactivation or equivalent

2017-09-27 Thread Lennart Poettering
On Di, 26.09.17 21:07, Matthew Giassa (matt...@giassa.net) wrote:

> Additionally, does systemd support assigning an environment variable to an 
> internal variable, ie:
> 
> Environment=MYPIDFILE=/var/run/mine.pid
> PIDFILE=$MYPIDFILE

systemd unit files are not supposed to be a templating engine. If you
want one use m4 or such.

Environment= configures the environment for the executed process,
that's all really.

> I know there are workarounds for ExecStart for example, using
> /bin/bash to evaluate environment variables, but I think that
> special case only applies to ExecStart, ExecStartPre, and Executor,
> as they actually get executed rather than just assigned, allowing
> for some degree of variable expansion.

Yes, ExecXYZ= do some basic variable expansion, and I regret these
days that I added that, it makes unit files a bit too magic, they are
supposed to be simply key-value files...

Note that the set of environment variables passed to executed
processes is the combination of a number of sources: the stuff from
Environment=, the stuff from EnvironmentFiles=, the system-wide
Environment=, the stuff pulled in via PassEnvironment=, the stuff set
via PAM modules (if PAMName= is used) as well as what systemd sets on
its own (MAINPID=, LISTEN_FDS=, NOTIFY_SOCKET= and such). Many of
these fields are only known at the moment of activation (for example,
MAINPID= is set to the main PID of a service, but that's only known if
we actually started that already), and hence we can't expand env vars
in other statements even if we wanted: loading configuration files
happens much much earlier than activation after all. Only in ExecXYZ=
we can do the minimal expansion we do, as right when we fork off the
process we actually know the environment we'll pass too.

Lennart

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


Re: [systemd-devel] Question: path-based deactivation or equivalent

2017-09-27 Thread Matthew Giassa
I've been considering the dbus API, as I arrived at a similar conclusion while 
researching this last night. The downside is that, since some services are 
provided to me in binary form only, I can't deploy it across all daemons. 

In short, I'd be happy with just being able to send SIGTERM and SIGKILL to 
systemd-managed daemons, along with spawning them on-demand, without having to 
do something along the lines of execve(systemctl...) (i.e. Directly via a C/C++ 
API), and not requiring root privileges to issue the call. ‎I don't see a way 
to do this directly via systemd without wrapping systemctl. 

Thank you for the feedback.

Sent from my BlackBerry 10 smartphone on the Bell network.
  Original Message  
From: Lennart Poettering
Sent: Wednesday, September 27, 2017 9:54 AM
To: matt...@giassa.net
Cc: systemd-devel@lists.freedesktop.org
Subject: Re: [systemd-devel] Question: path-based deactivation or equivalent

On Di, 26.09.17 16:15, matt...@giassa.net (matt...@giassa.net) wrote:

> I have a project where I'm adding some services to a Raspberry Pi 3,
> and have decided to go with systemd being (mostly) responsible for
> launching all of the services. All of the server processes use a common
> API to do some initial setup (argument parsing, init, etc), drop root
> permissions, and then carry out their normal duties. One of these
> services is the "master" service, which I want to use to
> activate/deactivate other services on-demand.
> 
> I started out with path-based activation via systemd, and that
> worked fine for bringing up the services as I requested them. However,
> it seems there is no equivalent path-based deactivation functionality at
> this time [1], so it's definitely not an option on the older OS deployed
> on my dev board.

Unit deactivation triggered by fs events has been requested before
(there's a github RFE issue about it somewhere), but I am not
convinced this is a good idea, and the semantics aren't clear about it
at all.

First of all, the states of .path units and the units they trigger are
actually connected: as long as the service a .path is supposed to
trigger is running the .path unit is in a "dormant" mode, and won't
care for any fs events, until the service is terminated again, at
which point the state is rechecked and things might trigger
again. This scheme is not compatible with .path based deactivation
really...

The other thing is: i fail to see the usecase. Things like PathExists=
and DirectoryNotEmpty= have a clear usecase where they aren't racy:
they trigger a service that processes files that are created somewhere
and delete the files when they are done with them. As long as there
are files there, the service will be restarted. And the service is
supposed to exit when it's done.

Now, if you want to use .path just a communication protocol: there are
way better ways to solve that. use systemctl, or use the D-Bus
API. File system objects are not a great replacement for an IPC.

Lennart

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


Re: [systemd-devel] Question: path-based deactivation or equivalent

2017-09-27 Thread Matthew Giassa

* Matthew Giassa  [2017-09-26 21:07:16 -0700]:


I know there are workarounds for ExecStart for example, using /bin/bash to 
evaluate environment variables, but I think that special case only applies to 
ExecStart, ExecStartPre, and Executor, as they actually get executed rather 
than just assigned, allowing for some degree of variable expansion.


Correction: ExecStart, ExecStartPre, and ExecStop.



Thank you.

Sent from my BlackBerry 10 smartphone on the Bell network.
  Original Message  
From: matt...@giassa.net
Sent: Tuesday, September 26, 2017 4:15 PM
To: systemd-devel@lists.freedesktop.org
Subject: Question: path-based deactivation or equivalent

I have a project where I'm adding some services to a Raspberry Pi 3,
and have decided to go with systemd being (mostly) responsible for
launching all of the services. All of the server processes use a common
API to do some initial setup (argument parsing, init, etc), drop root
permissions, and then carry out their normal duties. One of these
services is the "master" service, which I want to use to
activate/deactivate other services on-demand.

I started out with path-based activation via systemd, and that
worked fine for bringing up the services as I requested them. However,
it seems there is no equivalent path-based deactivation functionality at
this time [1], so it's definitely not an option on the older OS deployed
on my dev board.

I've looked into finding a suitable workaround, but the only viable
option so far is a hack that involves creating two separate systemd
scripts for a single service [2]. Is there some other functionality to
systemd that would permit me to:
-Activate and deactivate a service on demand (i.e. start it; stop it via
SIGNIT and after a timeout send it SIGKILL).
-Only have a single systemd script per service rather than the
two-scripts-per-service hack noted in [2].
-Allow a non-root (unprivileged) user to invoke my API/wrapper to
start/stop the services/daemons I maintain.
-Provide similar activation logic to path-based activation (i.e. only
start the service if both its dependencies on other services has been
met, AND the path/socket/etc exists).

Some of these services are provided to me in binary-only form, so I
can't necessarily modify all of them from source. Also, I'm not allowed
to use the LD_PRELOAD approach to injecting features. For all intents
and purposes, let's assume I can only modify my "manager" service, and
the systemd scripts for all services.

Thank you for your time and assistance.

Addendum:

I'm doing this to automate a test suite that evaulates how the
various services handle failure cases when one or more random services
goes up and down. The test suite, like the services/daemons themselves,
is not permitted root access, and has to be able to run as an
unprivileged user (i.e. no "systemctl $SERVICENAME start|stop" is
permitted via the command line). If there's an equivalent to the
path-based activation/deactivation as noted in [2], it makes my life a
lot easier.

Eventually, some services may be able to sidestep the "master"
service, and kill off other services (i.e. dependencies), so having the
"master" service just kill() the other services is not viable long-term.

References:

1. "RFE: systemd.path should support deactivation #3642",
, Last accessed 2017-09-26.

2. "Can I use systemd to start and stop a service based on the presence
of a file?",
,
Last accessed 2017-09-26.



--


Matthew Giassa, MASc, BASc, EIT
Principal Developer; Security and Embedded Systems Specialist
linkedin: https://ca.linkedin.com/in/giassa
e-mail:   matt...@giassa.net
website:  www.giassa.net


The information contained in this e-mail is intended only for the
individual or entity to whom it is addressed. Its contents (including
any attachments) are confidential and may contain privileged
information. If you are not the intended recipient you must not use,
disclose, disseminate, copy or print its contents.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Question: path-based deactivation or equivalent

2017-09-26 Thread Matthew Giassa
Additionally, does systemd support assigning an environment variable to an 
internal variable, ie:

Environment=MYPIDFILE=/var/run/mine.pid
PIDFILE=$MYPIDFILE

I know there are workarounds for ExecStart for example, using /bin/bash to 
evaluate environment variables, but I think that special case only applies to 
ExecStart, ExecStartPre, and Executor, as they actually get executed rather 
than just assigned, allowing for some degree of variable expansion.

There are a few systemd options I would like to set like this so that I don't 
have to type the same string literals twice (reduce chances of a typo causing a 
bug), and for the process to know certain systemd-related values without having 
to hard code them in systemd scripts and the project source (write once, use 
everywhere).

Thank you.

Sent from my BlackBerry 10 smartphone on the Bell network.
  Original Message  
From: matt...@giassa.net
Sent: Tuesday, September 26, 2017 4:15 PM
To: systemd-devel@lists.freedesktop.org
Subject: Question: path-based deactivation or equivalent

I have a project where I'm adding some services to a Raspberry Pi 3,
and have decided to go with systemd being (mostly) responsible for
launching all of the services. All of the server processes use a common
API to do some initial setup (argument parsing, init, etc), drop root
permissions, and then carry out their normal duties. One of these
services is the "master" service, which I want to use to
activate/deactivate other services on-demand.

I started out with path-based activation via systemd, and that
worked fine for bringing up the services as I requested them. However,
it seems there is no equivalent path-based deactivation functionality at
this time [1], so it's definitely not an option on the older OS deployed
on my dev board.

I've looked into finding a suitable workaround, but the only viable
option so far is a hack that involves creating two separate systemd
scripts for a single service [2]. Is there some other functionality to
systemd that would permit me to:
-Activate and deactivate a service on demand (i.e. start it; stop it via
SIGNIT and after a timeout send it SIGKILL).
-Only have a single systemd script per service rather than the
two-scripts-per-service hack noted in [2].
-Allow a non-root (unprivileged) user to invoke my API/wrapper to
start/stop the services/daemons I maintain.
-Provide similar activation logic to path-based activation (i.e. only
start the service if both its dependencies on other services has been
met, AND the path/socket/etc exists).

Some of these services are provided to me in binary-only form, so I
can't necessarily modify all of them from source. Also, I'm not allowed
to use the LD_PRELOAD approach to injecting features. For all intents
and purposes, let's assume I can only modify my "manager" service, and
the systemd scripts for all services.

Thank you for your time and assistance.

Addendum:

I'm doing this to automate a test suite that evaulates how the
various services handle failure cases when one or more random services
goes up and down. The test suite, like the services/daemons themselves,
is not permitted root access, and has to be able to run as an
unprivileged user (i.e. no "systemctl $SERVICENAME start|stop" is
permitted via the command line). If there's an equivalent to the
path-based activation/deactivation as noted in [2], it makes my life a
lot easier.

Eventually, some services may be able to sidestep the "master"
service, and kill off other services (i.e. dependencies), so having the
"master" service just kill() the other services is not viable long-term.

References:

1. "RFE: systemd.path should support deactivation #3642",
, Last accessed 2017-09-26.

2. "Can I use systemd to start and stop a service based on the presence
of a file?",
,
Last accessed 2017-09-26.

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


Re: [systemd-devel] [Question] timezones in timers

2017-09-09 Thread Ivan Kurnosov
Hi,

I've implemented support for timezones in timers (at least I am not sure if
there are some other places that need some changes).

Here is a diff of what I've committed so far:
https://github.com/systemd/systemd/compare/master...zerkms:TIMER_TIMEZONE

In the very bottom in the tests file you may see what is supported and how.
In short:

the IANA timezone name are supported. Basically, any timezone from the
`timedatectl list-timezones` output is supported.

The most basic example of the timer:

2017-09-09 20:42:00 Pacific/Auckland


Implementation takes into account standard/summer time change.

Implementation might be improved further via a small refactoring to remove
the `CalendarSpec::utc` field, since it effectively is not necessary now,
given that one may use `spec->timezone = "UTC";` instead.

I'm looking for your feedback,

thanks.

On 7 September 2017 at 08:12, Ivan Kurnosov  wrote:

> I'm doing it with the libc and doing it out of the process:
>
> https://github.com/zerkms/systemd/blob/d09815ef6df4705e06bd0b3a276c4c
> bd8630859f/src/basic/calendarspec.c#L902
>
> I believe parsing is portable standard C with libc and time conversion
> will be very similar to that.
>
> On 7 September 2017 at 01:25, Lennart Poettering 
> wrote:
>
>> On Mi, 06.09.17 13:18, Mantas Mikulėnas (graw...@gmail.com) wrote:
>>
>> > On Wed, Sep 6, 2017 at 12:58 PM, Ivan Kurnosov 
>> wrote:
>> >
>> > > I've started working on it (as a crazy experiment for myself
>> primarily)
>> > >
>> > > At the moment I added support for timezones (IANA) to the
>> `CalendarSpec`,
>> > > the parser and the formatter.
>> > >
>> > > https://github.com/zerkms/systemd/commit/367325ae7a2c4df2c05
>> > > 13e8bb8e9925aaf24feef
>> > >
>> >
>> > systemd actually used to have code for parsing *tzdata files* (and
>> showing
>> > DST information in timedatectl); you might want to find that in Git.
>>
>> While it did parse that I don't think we should go that route
>> here. When converting local time into unix time and back we really
>> should let the libc deal with that, and not replicate that. it's not
>> pretty to do this in libc, as there's no way to do time calculation in
>> a non-default timezone except by manipulating env vars, but it's
>> doable, as long as we do this out-of-process...
>>
>> Lennart
>>
>> --
>> Lennart Poettering, Red Hat
>>
>
>
>
> --
> With best regards, Ivan Kurnosov
>



-- 
With best regards, Ivan Kurnosov
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [Question] timezones in timers

2017-09-06 Thread Ivan Kurnosov
I'm doing it with the libc and doing it out of the process:

https://github.com/zerkms/systemd/blob/d09815ef6df4705e06bd0b3a276c4cbd8630859f/src/basic/calendarspec.c#L902

I believe parsing is portable standard C with libc and time conversion will
be very similar to that.

On 7 September 2017 at 01:25, Lennart Poettering 
wrote:

> On Mi, 06.09.17 13:18, Mantas Mikulėnas (graw...@gmail.com) wrote:
>
> > On Wed, Sep 6, 2017 at 12:58 PM, Ivan Kurnosov  wrote:
> >
> > > I've started working on it (as a crazy experiment for myself primarily)
> > >
> > > At the moment I added support for timezones (IANA) to the
> `CalendarSpec`,
> > > the parser and the formatter.
> > >
> > > https://github.com/zerkms/systemd/commit/367325ae7a2c4df2c05
> > > 13e8bb8e9925aaf24feef
> > >
> >
> > systemd actually used to have code for parsing *tzdata files* (and
> showing
> > DST information in timedatectl); you might want to find that in Git.
>
> While it did parse that I don't think we should go that route
> here. When converting local time into unix time and back we really
> should let the libc deal with that, and not replicate that. it's not
> pretty to do this in libc, as there's no way to do time calculation in
> a non-default timezone except by manipulating env vars, but it's
> doable, as long as we do this out-of-process...
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
>



-- 
With best regards, Ivan Kurnosov
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [Question] timezones in timers

2017-09-06 Thread Lennart Poettering
On Mi, 06.09.17 13:18, Mantas Mikulėnas (graw...@gmail.com) wrote:

> On Wed, Sep 6, 2017 at 12:58 PM, Ivan Kurnosov  wrote:
> 
> > I've started working on it (as a crazy experiment for myself primarily)
> >
> > At the moment I added support for timezones (IANA) to the `CalendarSpec`,
> > the parser and the formatter.
> >
> > https://github.com/zerkms/systemd/commit/367325ae7a2c4df2c05
> > 13e8bb8e9925aaf24feef
> >
> 
> systemd actually used to have code for parsing *tzdata files* (and showing
> DST information in timedatectl); you might want to find that in Git.

While it did parse that I don't think we should go that route
here. When converting local time into unix time and back we really
should let the libc deal with that, and not replicate that. it's not
pretty to do this in libc, as there's no way to do time calculation in
a non-default timezone except by manipulating env vars, but it's
doable, as long as we do this out-of-process...

Lennart

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


Re: [systemd-devel] [Question] timezones in timers

2017-09-06 Thread Mantas Mikulėnas
On Wed, Sep 6, 2017 at 12:58 PM, Ivan Kurnosov  wrote:

> I've started working on it (as a crazy experiment for myself primarily)
>
> At the moment I added support for timezones (IANA) to the `CalendarSpec`,
> the parser and the formatter.
>
> https://github.com/zerkms/systemd/commit/367325ae7a2c4df2c05
> 13e8bb8e9925aaf24feef
>

systemd actually used to have code for parsing *tzdata files* (and showing
DST information in timedatectl); you might want to find that in Git.

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


Re: [systemd-devel] [Question] timezones in timers

2017-09-06 Thread Ivan Kurnosov
I've started working on it (as a crazy experiment for myself primarily)

At the moment I added support for timezones (IANA) to the `CalendarSpec`,
the parser and the formatter.

https://github.com/zerkms/systemd/commit/367325ae7a2c4df2c0513e8bb8e992
5aaf24feef


On 5 September 2017 at 19:11, Lennart Poettering 
wrote:

> On Di, 05.09.17 09:41, Ivan Kurnosov (zer...@zerkms.ru) wrote:
>
> > Hi,
> >
> > was it even considered initially to have proper timezones support in
> timers?
> >
> > Or perhaps it is somewhere in the roadmap?
> >
> > In particular, I'm speaking of `[Timer] OnCalendar`
>
> You mean as in explicitly per-unit configurable timezones?
>
> It's nasty to do, since Linux APIs for that aren't really
> existent. But it's not impossible to do, but so far nobody put
> together a patch.
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
>



-- 
With best regards, Ivan Kurnosov
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [Question] timezones in timers

2017-09-05 Thread Lennart Poettering
On Di, 05.09.17 09:41, Ivan Kurnosov (zer...@zerkms.ru) wrote:

> Hi,
> 
> was it even considered initially to have proper timezones support in timers?
> 
> Or perhaps it is somewhere in the roadmap?
> 
> In particular, I'm speaking of `[Timer] OnCalendar`

You mean as in explicitly per-unit configurable timezones?

It's nasty to do, since Linux APIs for that aren't really
existent. But it's not impossible to do, but so far nobody put
together a patch. 

Lennart

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


Re: [systemd-devel] question about system reboot and shutdown

2017-08-09 Thread Lennart Poettering
On Mi, 09.08.17 11:28, Tilman Baumann (til...@baumann.name) wrote:

> In my experience, the only place where you can hook in a non racy way is
> in the kernel.

I fully agree with this btw. The only safe place if the kernel does
all this. Much like most other drivers UPS drivers should be in the
kernel. That way they can hook into the only really fully correct
place.

Using an initrd is the closest thing otherwise to close the race, but
actually it's still there then, as the kernel flushes ATA buffers and
such when reboot() is invoked, and any initrd-based userspace
implementation will ultimately still race against that...

Lennart

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


Re: [systemd-devel] question about system reboot and shutdown

2017-08-09 Thread Lennart Poettering
On Mi, 09.08.17 11:02, Marek Floriańczyk (marek.florianc...@gmail.com) wrote:

> The question is, will my binary be able to open RS232 port eg. /dev/ttyACM0 
> when filesystem is Read-Only ?

Yes, /dev is unaffected. It's an API VFS, not a real file system, and
those won't be remounted r/o.

> And if it is binary it will need to load some libs at least libc at
> the start.

As long as you use only libraries and other resources from the root fs
you should be fine. But you shouldn't reference /var, /home, /srv or /usr/local 
or
such, if you want to remain compatible with generic systems.

> The man page you pointed to says the parameter is: "halt", "poweroff", 
> "reboot" or "kexec", so the first two should work for me.

"halt" just halts the system. It shouldn't result in power being
turned off. It will just make the system freeze eventually, that's all.

Lennart

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


Re: [systemd-devel] question about system reboot and shutdown

2017-08-09 Thread Marek Floriańczyk
Dnia środa, 9 sierpnia 2017 14:54:25 CEST piszesz:
> 2017-08-09 14:51 GMT+02:00 Marek Floriańczyk :
> > Dnia środa, 9 sierpnia 2017 11:51:07 CEST Tilman Baumann pisze:
> >> On 09.08.2017 11:28, Tilman Baumann wrote:
> > NUT looks like quite active based on their website.
> > Microupsd daemon handles also some switches and leds for the end user, I
> > mean user can press some switch on the device and daemon will perform an
> > action described in configuration file, so porting everything to NUT
> > would take more time that I actually got for this.
> > 
> > Thank You all. I will try to write some simple binary, place it in
> > /lib/systemd/system-shutdown/
> > and test it.
> 
> Apparently nut uses this approach as well:
> https://packages.debian.org/sid/amd64/nut-server/filelist

Thanks for hint.

Marek

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


Re: [systemd-devel] question about system reboot and shutdown

2017-08-09 Thread Michael Biebl
2017-08-09 14:51 GMT+02:00 Marek Floriańczyk :
> Dnia środa, 9 sierpnia 2017 11:51:07 CEST Tilman Baumann pisze:
>> On 09.08.2017 11:28, Tilman Baumann wrote:
>
> NUT looks like quite active based on their website.
> Microupsd daemon handles also some switches and leds for the end user, I mean
> user can press some switch on the device and daemon will perform an action
> described in configuration file, so porting everything to NUT would take more
> time that I actually got for this.
>
> Thank You all. I will try to write some simple binary, place it in
> /lib/systemd/system-shutdown/
> and test it.
>


Apparently nut uses this approach as well:
https://packages.debian.org/sid/amd64/nut-server/filelist
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] question about system reboot and shutdown

2017-08-09 Thread Marek Floriańczyk
Dnia środa, 9 sierpnia 2017 11:51:07 CEST Tilman Baumann pisze:
> On 09.08.2017 11:28, Tilman Baumann wrote:
> > DL;DR
> > UPS shutdowns are tricky. Clean file-systems are not the only concern.
> > But if you can make assumptions about your storage backend you might be
> > able to cut corners safely.
> > 
> > In my experience, the only place where you can hook in a non racy way is
> > in the kernel.
> > 
> > https://unix.stackexchange.com/questions/122557/how-does-the-system-shutdo
> > wn-of-a-linux-kernel-work-internally
> Apologies, I copy and pasted the wrong link
> https://stackoverflow.com/questions/5938325/how-do-i-detect-reboot-shutdown-> 
> from-a-linux-driver
> 
> The magic is here IIRC
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree
> /kernel/reboot.c ___


NUT looks like quite active based on their website.
Microupsd daemon handles also some switches and leds for the end user, I mean 
user can press some switch on the device and daemon will perform an action 
described in configuration file, so porting everything to NUT would take more 
time that I actually got for this.

Thank You all. I will try to write some simple binary, place it in 
/lib/systemd/system-shutdown/
and test it.

Best Regards
Marek

> 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] question about system reboot and shutdown

2017-08-09 Thread Marek Floriańczyk
Dnia środa, 9 sierpnia 2017 09:17:44 CEST Mantas Mikulėnas pisze:
> /dev is a separate filesystem and is never read-only.

right ;)

> 
> Another approach would be to let microupsd exit normally, but then start a
> separate microupsd instance (e.g. microupsd-shutdown.service) which
> schedules the UPS poweroff.

Thanks for suggestion
I will stick to the approach suggested by Lennart it looks like a simple 
solution to me, and the binary is called at the very late stage of shutdown 
process after every databases and daemons are closed.

> 
> On Wed, Aug 9, 2017, 12:03 Marek Floriańczyk 
> 
> wrote:
> > Dnia środa, 9 sierpnia 2017 10:29:37 CEST Lennart Poettering pisze:
> > > On Di, 08.08.17 16:03, Marek Floriańczyk (marek.florianc...@gmail.com)
> > 
> > wrote:
> > > > Hi all,
> > > > 
> > > > I have a small device MicroUPS which helps me to shutdown my system on
> > > > embedded devices, it is controlled by script /etc/init.d/microups and
> > 
> > in
> > 
> > > > this script I need to know whether system is going down for reboot or
> > 
> > for
> > 
> > > > halt, because in case of halt I need to send small data over RS232 to
> > > > MicroUPS device to cut the power off.
> > > 
> > > Note that this is necessarily racy: you can't really know how long the
> > > system will actually take to shut down, hence if you trigger your
> > > hardware for shutdown at an early phase of the shutdown process you
> > > now start racing the remaining shutdown phase against the hardware
> > 
> > turning
> > 
> > > off power...
> > > 
> > > If you want to fix this properly, and remove this race entirely the
> > > only fully correct way out I see is to use an initrd for booting, and
> > > doing the RS232 thing from that. Note that if you use a properly
> > > prepared initrd, systemd will actually transition back to it at
> > > shutdown, and while doing so it will permit unmounting the root file
> > > system properly at shutdown. And only if you start the RS232 thing
> > > after the point where the root fs is unmounted you can fully remove
> > > the race in the generic case, since only at that point everything is
> > > fully synced to disk, all complex storage is disassembled and so on.
> > > 
> > > Now, adding this to the initrd is not the easiest thing in the world,
> > > and in particular in embedded devices avoiding an initrd might be a
> > > good thing. As long as you have no complex storage (i.e. no DM, no
> > > LVM, no LUKS, no RAID, no iscsi, yaddayadda) you can instead cut a
> > > corner and just drop in a shutdown script to
> > > /usr/lib/systemd/system-shutdown/. All executable files in that
> > > directory are run at very late boot, at a point where all file systems
> > > that can be unmounted have been unmounted and the rest have been
> > > remounted read-only (i.e. the root fs will be r/o and everything else
> > > is gone). All services are gone at that point too, hence you live in a
> > > very minimal, very reduced environment. If you issue your RS232
> > > commands from that environment you should be mostly good. (but again,
> > > if you do complex storage all of this falls apart, and you have to do
> > > the initrd thing instead).
> > > 
> > > Note that /usr/lib/systemd/system-shutdown/ is outside of usual
> > > service management. It's run at a point where service management is
> > > already turned off. As such, you really just drop executable scripts
> > > or binaries there, and nothing long-running, no daemons or such, just
> > > simple programs that run and exit.
> > > 
> > > For details about this facility see the systemd-halt.service(8) man
> > > page. The scripts executed that way will get one parameter, which
> > > tells it what operation is being executed. And if its "poweroff", then
> > > you know that the system is going down for powering off rather than
> > > reboot.
> > 
> > Hi,
> > 
> > This looks like a good way for me.
> > I cannot really use initrd, because my MicroUPS is intended to work not
> > only
> > for me but also for an average people, with some .deb package to install.
> > This is an early version of my device, now it looks different, has higher
> > power output and so on
> > 
> > https://www.indiegogo.com/projects/microups-for-raspberry-beaglebone-cubie
> > board#/
> > 
> > 
> > I'm aware of race condition but some microcomputers like Raspberry if they
> > shutdown the operating system, the power is still ON, and I have no way to
> > figure out when to turn power off. So what I'm doing is telling microups
> > device
> > to cut power off 30 seconds after shutdown has been initiated (parameter
> > is
> > configurable).
> > Microcomputers usually have some SD card, sometimes built-in NAND memory,
> > and
> > sometimes single SATA SSD disk, so complex storage is not an issue (I
> > think)
> > 
> > The question is, will my binary be able to open RS232 port eg.
> > /dev/ttyACM0
> > when filesystem is Read-Only ?
> > And if it is binary it will need to load some 

Re: [systemd-devel] question about system reboot and shutdown

2017-08-09 Thread Tilman Baumann
On 09.08.2017 11:28, Tilman Baumann wrote:
> DL;DR
> UPS shutdowns are tricky. Clean file-systems are not the only concern.
> But if you can make assumptions about your storage backend you might be
> able to cut corners safely.
> 
> In my experience, the only place where you can hook in a non racy way is
> in the kernel.
> 
> https://unix.stackexchange.com/questions/122557/how-does-the-system-shutdown-of-a-linux-kernel-work-internally

Apologies, I copy and pasted the wrong link
https://stackoverflow.com/questions/5938325/how-do-i-detect-reboot-shutdown-from-a-linux-driver

The magic is here IIRC
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/kernel/reboot.c
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] question about system reboot and shutdown

2017-08-09 Thread Tilman Baumann
DL;DR
UPS shutdowns are tricky. Clean file-systems are not the only concern.
But if you can make assumptions about your storage backend you might be
able to cut corners safely.

In my experience, the only place where you can hook in a non racy way is
in the kernel.

https://unix.stackexchange.com/questions/122557/how-does-the-system-shutdown-of-a-linux-kernel-work-internally

Because this is the hook which a lot of RAID systems and storage
back-ends use to signal a clean poweroff.
If you just halt your system very late in shutdown in userspace and
switch the lights off, the kernel will never run this code.
The result is that for example RAID unclean flags are still set.

UPS kernel drivers generally solve this problem by setting a 'powerfail'
flag before they initiate a shutdown.
The driver is hooked in the shutdown notifier and initiates the poweroff
through the UPS.

Another race condition is, that during the shutdown, the power could
have come back. THE UPS needs to recognize that and still power off the
system to ensure a reboot and then switch it back on.

But I think in your case, using a time based approach is quite valid.
Late in shutdown, set the powerfail flag in the UPS and set a poweroff
timer. While that timer is ticking in the UPS, your system will continue
shutting down safely and halt. And when the timer ran out the UPS will
switch the lights off.
That is by nature racy. But in a well defined system I suppose the risk
is manageable.


Mind you, my exposure tho this stuff is 10 years old or so. A lot might
have happened since then.
Back then I was fighting with a APC UPS which did not support timer
based poweroff and in combination with a 3ware RAID controller lead to
degraded volumes after powerfail.
The shutdown was done in userspace and the UPS did not know timer based
shutdowns. Hence the kernel hook never ran.

BTW. if you don't want to reinvent the wheel. networkupstools (NUT) was
back then the only really sensible software stack that did in practice
most things right.
As I said. My experience is 10 years dated. And I don't know if NUT
works well with systemd. And of course a network based system is
overkill. But perhaps you can have a look at it for some 'best practices'


On 09.08.2017 11:02, Marek Floriańczyk wrote:
> Dnia środa, 9 sierpnia 2017 10:29:37 CEST Lennart Poettering pisze:
>> On Di, 08.08.17 16:03, Marek Floriańczyk (marek.florianc...@gmail.com) wrote:
>>> Hi all,
>>>
>>> I have a small device MicroUPS which helps me to shutdown my system on
>>> embedded devices, it is controlled by script /etc/init.d/microups and in
>>> this script I need to know whether system is going down for reboot or for
>>> halt, because in case of halt I need to send small data over RS232 to
>>> MicroUPS device to cut the power off.
>>
>> Note that this is necessarily racy: you can't really know how long the
>> system will actually take to shut down, hence if you trigger your
>> hardware for shutdown at an early phase of the shutdown process you
>> now start racing the remaining shutdown phase against the hardware turning
>> off power...
>>
>> If you want to fix this properly, and remove this race entirely the
>> only fully correct way out I see is to use an initrd for booting, and
>> doing the RS232 thing from that. Note that if you use a properly
>> prepared initrd, systemd will actually transition back to it at
>> shutdown, and while doing so it will permit unmounting the root file
>> system properly at shutdown. And only if you start the RS232 thing
>> after the point where the root fs is unmounted you can fully remove
>> the race in the generic case, since only at that point everything is
>> fully synced to disk, all complex storage is disassembled and so on.
>>
>> Now, adding this to the initrd is not the easiest thing in the world,
>> and in particular in embedded devices avoiding an initrd might be a
>> good thing. As long as you have no complex storage (i.e. no DM, no
>> LVM, no LUKS, no RAID, no iscsi, yaddayadda) you can instead cut a
>> corner and just drop in a shutdown script to
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] question about system reboot and shutdown

2017-08-09 Thread Mantas Mikulėnas
/dev is a separate filesystem and is never read-only.

Another approach would be to let microupsd exit normally, but then start a
separate microupsd instance (e.g. microupsd-shutdown.service) which
schedules the UPS poweroff.

On Wed, Aug 9, 2017, 12:03 Marek Floriańczyk 
wrote:

> Dnia środa, 9 sierpnia 2017 10:29:37 CEST Lennart Poettering pisze:
> > On Di, 08.08.17 16:03, Marek Floriańczyk (marek.florianc...@gmail.com)
> wrote:
> > > Hi all,
> > >
> > > I have a small device MicroUPS which helps me to shutdown my system on
> > > embedded devices, it is controlled by script /etc/init.d/microups and
> in
> > > this script I need to know whether system is going down for reboot or
> for
> > > halt, because in case of halt I need to send small data over RS232 to
> > > MicroUPS device to cut the power off.
> >
> > Note that this is necessarily racy: you can't really know how long the
> > system will actually take to shut down, hence if you trigger your
> > hardware for shutdown at an early phase of the shutdown process you
> > now start racing the remaining shutdown phase against the hardware
> turning
> > off power...
> >
> > If you want to fix this properly, and remove this race entirely the
> > only fully correct way out I see is to use an initrd for booting, and
> > doing the RS232 thing from that. Note that if you use a properly
> > prepared initrd, systemd will actually transition back to it at
> > shutdown, and while doing so it will permit unmounting the root file
> > system properly at shutdown. And only if you start the RS232 thing
> > after the point where the root fs is unmounted you can fully remove
> > the race in the generic case, since only at that point everything is
> > fully synced to disk, all complex storage is disassembled and so on.
> >
> > Now, adding this to the initrd is not the easiest thing in the world,
> > and in particular in embedded devices avoiding an initrd might be a
> > good thing. As long as you have no complex storage (i.e. no DM, no
> > LVM, no LUKS, no RAID, no iscsi, yaddayadda) you can instead cut a
> > corner and just drop in a shutdown script to
> > /usr/lib/systemd/system-shutdown/. All executable files in that
> > directory are run at very late boot, at a point where all file systems
> > that can be unmounted have been unmounted and the rest have been
> > remounted read-only (i.e. the root fs will be r/o and everything else
> > is gone). All services are gone at that point too, hence you live in a
> > very minimal, very reduced environment. If you issue your RS232
> > commands from that environment you should be mostly good. (but again,
> > if you do complex storage all of this falls apart, and you have to do
> > the initrd thing instead).
> >
> > Note that /usr/lib/systemd/system-shutdown/ is outside of usual
> > service management. It's run at a point where service management is
> > already turned off. As such, you really just drop executable scripts
> > or binaries there, and nothing long-running, no daemons or such, just
> > simple programs that run and exit.
> >
> > For details about this facility see the systemd-halt.service(8) man
> > page. The scripts executed that way will get one parameter, which
> > tells it what operation is being executed. And if its "poweroff", then
> > you know that the system is going down for powering off rather than
> > reboot.
>
> Hi,
>
> This looks like a good way for me.
> I cannot really use initrd, because my MicroUPS is intended to work not
> only
> for me but also for an average people, with some .deb package to install.
> This is an early version of my device, now it looks different, has higher
> power output and so on
>
> https://www.indiegogo.com/projects/microups-for-raspberry-beaglebone-cubieboard#/
>
>
> I'm aware of race condition but some microcomputers like Raspberry if they
> shutdown the operating system, the power is still ON, and I have no way to
> figure out when to turn power off. So what I'm doing is telling microups
> device
> to cut power off 30 seconds after shutdown has been initiated (parameter is
> configurable).
> Microcomputers usually have some SD card, sometimes built-in NAND memory,
> and
> sometimes single SATA SSD disk, so complex storage is not an issue (I
> think)
>
> The question is, will my binary be able to open RS232 port eg. /dev/ttyACM0
> when filesystem is Read-Only ?
> And if it is binary it will need to load some libs at least libc at the
> start.
>
> The man page you pointed to says the parameter is: "halt", "poweroff",
> "reboot" or "kexec", so the first two should work for me.
>
> Best Regards
> Marek
>
>
> >
> > Lennart
>
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
-- 

Mantas Mikulėnas 
Sent from my phone
___
systemd-devel mailing list

Re: [systemd-devel] question about system reboot and shutdown

2017-08-09 Thread Marek Floriańczyk
Dnia środa, 9 sierpnia 2017 10:29:37 CEST Lennart Poettering pisze:
> On Di, 08.08.17 16:03, Marek Floriańczyk (marek.florianc...@gmail.com) wrote:
> > Hi all,
> > 
> > I have a small device MicroUPS which helps me to shutdown my system on
> > embedded devices, it is controlled by script /etc/init.d/microups and in
> > this script I need to know whether system is going down for reboot or for
> > halt, because in case of halt I need to send small data over RS232 to
> > MicroUPS device to cut the power off.
> 
> Note that this is necessarily racy: you can't really know how long the
> system will actually take to shut down, hence if you trigger your
> hardware for shutdown at an early phase of the shutdown process you
> now start racing the remaining shutdown phase against the hardware turning
> off power...
> 
> If you want to fix this properly, and remove this race entirely the
> only fully correct way out I see is to use an initrd for booting, and
> doing the RS232 thing from that. Note that if you use a properly
> prepared initrd, systemd will actually transition back to it at
> shutdown, and while doing so it will permit unmounting the root file
> system properly at shutdown. And only if you start the RS232 thing
> after the point where the root fs is unmounted you can fully remove
> the race in the generic case, since only at that point everything is
> fully synced to disk, all complex storage is disassembled and so on.
> 
> Now, adding this to the initrd is not the easiest thing in the world,
> and in particular in embedded devices avoiding an initrd might be a
> good thing. As long as you have no complex storage (i.e. no DM, no
> LVM, no LUKS, no RAID, no iscsi, yaddayadda) you can instead cut a
> corner and just drop in a shutdown script to
> /usr/lib/systemd/system-shutdown/. All executable files in that
> directory are run at very late boot, at a point where all file systems
> that can be unmounted have been unmounted and the rest have been
> remounted read-only (i.e. the root fs will be r/o and everything else
> is gone). All services are gone at that point too, hence you live in a
> very minimal, very reduced environment. If you issue your RS232
> commands from that environment you should be mostly good. (but again,
> if you do complex storage all of this falls apart, and you have to do
> the initrd thing instead).
> 
> Note that /usr/lib/systemd/system-shutdown/ is outside of usual
> service management. It's run at a point where service management is
> already turned off. As such, you really just drop executable scripts
> or binaries there, and nothing long-running, no daemons or such, just
> simple programs that run and exit.
> 
> For details about this facility see the systemd-halt.service(8) man
> page. The scripts executed that way will get one parameter, which
> tells it what operation is being executed. And if its "poweroff", then
> you know that the system is going down for powering off rather than
> reboot.

Hi,

This looks like a good way for me.
I cannot really use initrd, because my MicroUPS is intended to work not only 
for me but also for an average people, with some .deb package to install.
This is an early version of my device, now it looks different, has higher 
power output and so on
https://www.indiegogo.com/projects/microups-for-raspberry-beaglebone-cubieboard#/


I'm aware of race condition but some microcomputers like Raspberry if they 
shutdown the operating system, the power is still ON, and I have no way to 
figure out when to turn power off. So what I'm doing is telling microups device 
to cut power off 30 seconds after shutdown has been initiated (parameter is 
configurable). 
Microcomputers usually have some SD card, sometimes built-in NAND memory, and 
sometimes single SATA SSD disk, so complex storage is not an issue (I think)

The question is, will my binary be able to open RS232 port eg. /dev/ttyACM0 
when filesystem is Read-Only ?
And if it is binary it will need to load some libs at least libc at the start.

The man page you pointed to says the parameter is: "halt", "poweroff", 
"reboot" or "kexec", so the first two should work for me.

Best Regards
Marek


> 
> Lennart


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


Re: [systemd-devel] question about system reboot and shutdown

2017-08-09 Thread Jérémy Rosen

Hi

I have no problem with changing some code in microupsd so it behave in certain
way. It is handling SIGTERM and other signals if needed.
The problem for me is that SIGTERM is send to process during system reboot and
system halt - so I need to differentiate between the two.

SIGTERM is sent, by default, to all processes early during shutdown.

You need to disable DefaultDependencies for your process to not recieve
the default SIGTERM and then trigger it yourself with the WandedBy that
was already described...


Your daemon is a late-shutdown daemon, not a normal daemon. I think
that deactivating default dependencies in this case makes sense.

I strongly advice carefully reading the section on default dependencies in
systemd.service, though... You will deactivate all default dependencies and
you probably don't want that. You'll need to manually reactivate the other
default dependencies

BR
Jérémy

If you can suggest me  a way, maybe with some example I will change my code.

Best Regards
Marek


Normally services are given a certain amount of time to stop after SIGTERM
(or whatever KillSignal was set, or whatever ExecStop command was
specified). Even if microupsd doesn't handle SIGTERM nicely (which I'd call
a bug), it's possible to add some... arbitrary delays.

Units are stopped due to having automatic Conflicts=shutdown.target, if I
remember correctly. I'm not sure if disabling that default dependency is a
good approach though...

This time I can't think of a good combination that'd solve both problems
without introducing some ugly race conditions...

On Tue, Aug 8, 2017, 21:46 Marek Floriańczyk 

wrote:

Dnia wtorek, 8 sierpnia 2017 21:04:18 CEST Andrei Borzenkov pisze:

08.08.2017 17:03, Marek Floriańczyk пишет:

What would be the proper way to distinguish between system is going

down


for reboot and for shutdown ?

Straightforward way is to make your service WantedBy poweroff.target and
halt.target. You can then have second service WantedBy reboot.target and
kexec.target. They may even call the same binary (script) but with
different arguments.

Thanks for answer,

So, my binary "microupsd" is started  by /etc/init.d/microups at the boot
time
to monitor power input, battery status etc.
During system halt I need to send SIGUSR1 to this "microupsd" process at
which
it will send command to microups device, moreover  I would like to give it
some time (like 1-2 seconds) to accomplish the transmission.
I don't need to send anything in case of reboot.

Should I prepare some script that sends SIGUSR1 to "microupsd" process and
then sleeps for 2 seconds and set it as WantedBy poweroff.target and
halt.target ?

How can I be sure that this script will be called before "microupsd" is
actually killed during system shutdown ?

Best Regards
Marek

___
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


--
Logo 

20 rue des Jardins
92600 Asnières-sur-Seine
www.smile.fr    
*Jérémy ROSEN*
Architecte technique
Email : jeremy.ro...@smile.fr 
Tel : +33141402967

Facebook  Google%2B 
 LinkedIn 
 Twitter 




bandeaux_mail 



eco Pour la planète, n'imprimez ce mail que si c'est nécessaire
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] question about system reboot and shutdown

2017-08-08 Thread Marek Floriańczyk
Dnia wtorek, 8 sierpnia 2017 19:35:12 CEST Mantas Mikulėnas pisze:
> I suggest first porting microupsd itself to a native systemd .service file
> (so that it'll have process monitoring and everything). That might even fix
> part of the problem.

Hi

I have no problem with changing some code in microupsd so it behave in certain 
way. It is handling SIGTERM and other signals if needed.
The problem for me is that SIGTERM is send to process during system reboot and 
system halt - so I need to differentiate between the two.

If you can suggest me  a way, maybe with some example I will change my code.

Best Regards
Marek

> 
> Normally services are given a certain amount of time to stop after SIGTERM
> (or whatever KillSignal was set, or whatever ExecStop command was
> specified). Even if microupsd doesn't handle SIGTERM nicely (which I'd call
> a bug), it's possible to add some... arbitrary delays.
> 
> Units are stopped due to having automatic Conflicts=shutdown.target, if I
> remember correctly. I'm not sure if disabling that default dependency is a
> good approach though...
> 
> This time I can't think of a good combination that'd solve both problems
> without introducing some ugly race conditions...
> 
> On Tue, Aug 8, 2017, 21:46 Marek Floriańczyk 
> 
> wrote:
> > Dnia wtorek, 8 sierpnia 2017 21:04:18 CEST Andrei Borzenkov pisze:
> > > 08.08.2017 17:03, Marek Floriańczyk пишет:
> > > > What would be the proper way to distinguish between system is going
> > 
> > down
> > 
> > > > for reboot and for shutdown ?
> > > 
> > > Straightforward way is to make your service WantedBy poweroff.target and
> > > halt.target. You can then have second service WantedBy reboot.target and
> > > kexec.target. They may even call the same binary (script) but with
> > > different arguments.
> > 
> > Thanks for answer,
> > 
> > So, my binary "microupsd" is started  by /etc/init.d/microups at the boot
> > time
> > to monitor power input, battery status etc.
> > During system halt I need to send SIGUSR1 to this "microupsd" process at
> > which
> > it will send command to microups device, moreover  I would like to give it
> > some time (like 1-2 seconds) to accomplish the transmission.
> > I don't need to send anything in case of reboot.
> > 
> > Should I prepare some script that sends SIGUSR1 to "microupsd" process and
> > then sleeps for 2 seconds and set it as WantedBy poweroff.target and
> > halt.target ?
> > 
> > How can I be sure that this script will be called before "microupsd" is
> > actually killed during system shutdown ?
> > 
> > Best Regards
> > Marek
> > 
> > ___
> > 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] question about system reboot and shutdown

2017-08-08 Thread Mantas Mikulėnas
I suggest first porting microupsd itself to a native systemd .service file
(so that it'll have process monitoring and everything). That might even fix
part of the problem.

Normally services are given a certain amount of time to stop after SIGTERM
(or whatever KillSignal was set, or whatever ExecStop command was
specified). Even if microupsd doesn't handle SIGTERM nicely (which I'd call
a bug), it's possible to add some... arbitrary delays.

Units are stopped due to having automatic Conflicts=shutdown.target, if I
remember correctly. I'm not sure if disabling that default dependency is a
good approach though...

This time I can't think of a good combination that'd solve both problems
without introducing some ugly race conditions...

On Tue, Aug 8, 2017, 21:46 Marek Floriańczyk 
wrote:

> Dnia wtorek, 8 sierpnia 2017 21:04:18 CEST Andrei Borzenkov pisze:
> > 08.08.2017 17:03, Marek Floriańczyk пишет:
> > > What would be the proper way to distinguish between system is going
> down
> > > for reboot and for shutdown ?
> >
> > Straightforward way is to make your service WantedBy poweroff.target and
> > halt.target. You can then have second service WantedBy reboot.target and
> > kexec.target. They may even call the same binary (script) but with
> > different arguments.
>
> Thanks for answer,
>
> So, my binary "microupsd" is started  by /etc/init.d/microups at the boot
> time
> to monitor power input, battery status etc.
> During system halt I need to send SIGUSR1 to this "microupsd" process at
> which
> it will send command to microups device, moreover  I would like to give it
> some time (like 1-2 seconds) to accomplish the transmission.
> I don't need to send anything in case of reboot.
>
> Should I prepare some script that sends SIGUSR1 to "microupsd" process and
> then sleeps for 2 seconds and set it as WantedBy poweroff.target and
> halt.target ?
>
> How can I be sure that this script will be called before "microupsd" is
> actually killed during system shutdown ?
>
> Best Regards
> Marek
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
-- 

Mantas Mikulėnas 
Sent from my phone
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] question about system reboot and shutdown

2017-08-08 Thread Marek Floriańczyk
Dnia wtorek, 8 sierpnia 2017 21:04:18 CEST Andrei Borzenkov pisze:
> 08.08.2017 17:03, Marek Floriańczyk пишет:
> > What would be the proper way to distinguish between system is going down
> > for reboot and for shutdown ?
> 
> Straightforward way is to make your service WantedBy poweroff.target and
> halt.target. You can then have second service WantedBy reboot.target and
> kexec.target. They may even call the same binary (script) but with
> different arguments.

Thanks for answer,

So, my binary "microupsd" is started  by /etc/init.d/microups at the boot time 
to monitor power input, battery status etc.
During system halt I need to send SIGUSR1 to this "microupsd" process at which 
it will send command to microups device, moreover  I would like to give it 
some time (like 1-2 seconds) to accomplish the transmission.
I don't need to send anything in case of reboot.

Should I prepare some script that sends SIGUSR1 to "microupsd" process and 
then sleeps for 2 seconds and set it as WantedBy poweroff.target and 
halt.target ?

How can I be sure that this script will be called before "microupsd" is 
actually killed during system shutdown ?

Best Regards
Marek

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


Re: [systemd-devel] question about system reboot and shutdown

2017-08-08 Thread Andrei Borzenkov
08.08.2017 17:03, Marek Floriańczyk пишет:
> 
> What would be the proper way to distinguish between system is going down for 
> reboot and for shutdown ?
> 

Straightforward way is to make your service WantedBy poweroff.target and
halt.target. You can then have second service WantedBy reboot.target and
kexec.target. They may even call the same binary (script) but with
different arguments.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Question about systemd-firstboot

2017-03-09 Thread Francis Moreau
On Thu, Mar 9, 2017 at 5:49 PM, Zbigniew Jędrzejewski-Szmek
 wrote:
>> So if 'ro' is used, systemd-firstboot is not working. If it's expected
>> I think it would worth a note in the documentation.
> It's supposed to work, I think. Please open an issue, it'll be better
> tracked there.
>

https://github.com/systemd/systemd/issues/5562

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


Re: [systemd-devel] Question about systemd-firstboot

2017-03-09 Thread Zbigniew Jędrzejewski-Szmek
On Thu, Mar 09, 2017 at 05:31:46PM +0100, Francis Moreau wrote:
> On Thu, Mar 9, 2017 at 5:19 PM, Zbigniew Jędrzejewski-Szmek
>  wrote:
> > It depends on the command-line parameters: 'ro' and 'rw' both work.
> > 'rw' is actually recommended if you're using an initramfs.
> who is recommending 'rw' ?
That's how I remember the result of the discussions on systemd-devel
when we were trying to get systemd-fsck to work properly on all
combinations of ro/rw and fs type. I don't think there's any official
recommendation, just the general agreement that fsck is done better
in the initramfs (if at all needed, since most filesystems don't
really need it), and then there's no point in having the root temporarilly
read-only in the real system.

> > Otherwise, an empty /etc/machine-id may be present, if /etc is read-only
> > at boot, in which case systemd will do a temporary mount.
> >
> > So 'ro' is supported, but you either need an /etc/machine-id file or
> > a place to mount one temporarily.
> 
> So if 'ro' is used, systemd-firstboot is not working. If it's expected
> I think it would worth a note in the documentation.
It's supposed to work, I think. Please open an issue, it'll be better
tracked there.

Zbyszek

> On my setup, neither 'rw' nor 'ro' is passed so I assume 'ro' is the default.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Question about systemd-firstboot

2017-03-09 Thread Francis Moreau
On Thu, Mar 9, 2017 at 5:19 PM, Zbigniew Jędrzejewski-Szmek
 wrote:
> It depends on the command-line parameters: 'ro' and 'rw' both work.
> 'rw' is actually recommended if you're using an initramfs.
>

who is recommending 'rw' ?

do you have any pointers ?

> Otherwise, an empty /etc/machine-id may be present, if /etc is read-only
> at boot, in which case systemd will do a temporary mount.
>
> So 'ro' is supported, but you either need an /etc/machine-id file or
> a place to mount one temporarily.

So if 'ro' is used, systemd-firstboot is not working. If it's expected
I think it would worth a note in the documentation.

On my setup, neither 'rw' nor 'ro' is passed so I assume 'ro' is the default.

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


Re: [systemd-devel] Question about systemd-firstboot

2017-03-09 Thread Zbigniew Jędrzejewski-Szmek
On Thu, Mar 09, 2017 at 03:49:51PM +0100, Francis Moreau wrote:
> On Thu, Mar 9, 2017 at 3:10 PM, Zbigniew Jędrzejewski-Szmek
>  wrote:
> > On Thu, Mar 09, 2017 at 10:48:03AM +0100, Francis Moreau wrote:
> >> Hello,
> >>
> >> I'm puzzled about systemd-firstboot service.
> >>
> >> In my understanding this service is ran only during the firstboot. The
> >> firstboot condition is detected with the presence of /etc/machine-id
> >> file.
> >>
> >> If this file is not present then it's assumed to be a first boot and
> >> systemd-firstboot.service is ran and will create the machine-id file.
> >>
> >> Now the thing is that I dont see how systemd-firstboot.service can
> >> have a chance to be started because if /etc/machine-id is missing the
> >> whole boot is failing due to journald requiring /etc/machine-id.
> >>
> >> Could anybody give me some clues ?
> >
> > machine_id_setup() is called from main(). So pid1 should set up
> > /etc/machine-id if possible (/etc is wriable) before it starts the
> > firstboot services.
> >
> 
> For regular boots /etc is always RO when systemd is started, at least
> in my understanding.
It depends on the command-line parameters: 'ro' and 'rw' both work.
'rw' is actually recommended if you're using an initramfs.

Otherwise, an empty /etc/machine-id may be present, if /etc is read-only
at boot, in which case systemd will do a temporary mount.

So 'ro' is supported, but you either need an /etc/machine-id file or
a place to mount one temporarily.

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


Re: [systemd-devel] Question about systemd-firstboot

2017-03-09 Thread Francis Moreau
On Thu, Mar 9, 2017 at 3:10 PM, Zbigniew Jędrzejewski-Szmek
 wrote:
> On Thu, Mar 09, 2017 at 10:48:03AM +0100, Francis Moreau wrote:
>> Hello,
>>
>> I'm puzzled about systemd-firstboot service.
>>
>> In my understanding this service is ran only during the firstboot. The
>> firstboot condition is detected with the presence of /etc/machine-id
>> file.
>>
>> If this file is not present then it's assumed to be a first boot and
>> systemd-firstboot.service is ran and will create the machine-id file.
>>
>> Now the thing is that I dont see how systemd-firstboot.service can
>> have a chance to be started because if /etc/machine-id is missing the
>> whole boot is failing due to journald requiring /etc/machine-id.
>>
>> Could anybody give me some clues ?
>
> machine_id_setup() is called from main(). So pid1 should set up
> /etc/machine-id if possible (/etc is wriable) before it starts the
> firstboot services.
>

For regular boots /etc is always RO when systemd is started, at least
in my understanding.

Just give it a try, remove /etc/machine-id and reboots, you'll see
that journald will fail.

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


Re: [systemd-devel] Question about systemd-firstboot

2017-03-09 Thread Zbigniew Jędrzejewski-Szmek
On Thu, Mar 09, 2017 at 10:48:03AM +0100, Francis Moreau wrote:
> Hello,
> 
> I'm puzzled about systemd-firstboot service.
> 
> In my understanding this service is ran only during the firstboot. The
> firstboot condition is detected with the presence of /etc/machine-id
> file.
> 
> If this file is not present then it's assumed to be a first boot and
> systemd-firstboot.service is ran and will create the machine-id file.
> 
> Now the thing is that I dont see how systemd-firstboot.service can
> have a chance to be started because if /etc/machine-id is missing the
> whole boot is failing due to journald requiring /etc/machine-id.
> 
> Could anybody give me some clues ?

machine_id_setup() is called from main(). So pid1 should set up
/etc/machine-id if possible (/etc is wriable) before it starts the
firstboot services.

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


Re: [systemd-devel] question regarding DBUS_SESSION_BUS_ADDRESS in multiseat environment

2017-01-16 Thread Simon McVittie
On Sat, 03 Dec 2016 at 11:18:43 +0530, MohanR wrote:
> I'm looking through this --enable-user-session in dbus-daemon. Even if
> I enable that option, how can I retrive uniq DBUS_SESSION_BUS_ADDRESS
> from systemd started dbus-daemon to pass it to gnome-session?

I suggest taking a look at how it has been done in an OS distribution that
integrates --enable-user-session, such as Debian (with the dbus-user-session
package), Fedora or Arch Linux.

The socket used for the systemd-started dbus-daemon is predictable per-uid,
and recent versions of the major D-Bus implementations (libdbus, GDBus,
sd-bus) all try that socket before autostarting a new one.

Setting DBUS_SESSION_BUS_ADDRESS is only necessary to be nice to minor
D-Bus implementations (ndesk-dbus, dbus-java, etc.) or programs that
second-guess how D-Bus works (which currently includes gnome-session,
).

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


Re: [systemd-devel] question regarding DBUS_SESSION_BUS_ADDRESS in multiseat environment

2016-12-02 Thread MohanR
On Fri, 2016-12-02 at 12:28 +, Simon McVittie wrote:
> Does this mean your user is trying to be physically present in two
> places
> at the same time? How is this a useful thing to do? :-)

I thought the same when I came across this requirement. People
explained me that the admins who are going to use our solution will
mostly be Windows Admins and they are scared (or lazy) to create
different accounts for each people. They also said this kind of setup
possible in Windows (but I don't know exactly how it works) and they
will require that kind of setup in Linux too.

> pam_systemd does not do this unless you have configured dbus-daemon
> to provide one bus per logind user-session
> (./configure --enable-user-session), which is not the default.
> Either you or your OS vendor have explicitly chosen this model: if
> that
> doesn't match your requirements, you need to revert this choice.
> 
> If you require multiple D-Bus sessions per logind user-session, you
> must
> either configure dbus without --enable-user-session (the default is
> equivalent to --disable-user-session), or mask or remove the
> dbus.service and dbus.socket systemd user units that are installed
> by enabling that option (/usr/lib/systemd/dbus.*).

I'm looking through this --enable-user-session in dbus-daemon. Even if
I enable that option, how can I retrive uniq DBUS_SESSION_BUS_ADDRESS
from systemd started dbus-daemon to pass it to gnome-session?

I think this is a silly requirement and will make our display-manager
stop user starting two sessions by checking with logind whether that
user already have a graphical session.

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


Re: [systemd-devel] question regarding DBUS_SESSION_BUS_ADDRESS in multiseat environment

2016-12-02 Thread Jóhann B . Guðmundsson

On 12/02/2016 12:28 PM, Simon McVittie wrote:


Does this mean your user is trying to be physically present in two places
at the same time? How is this a useful thing to do?:-)


Clones are very useful things to have.

You just sit a drink a pina colada in hut in bora bora while they do all 
the hard work ;)


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


Re: [systemd-devel] question regarding DBUS_SESSION_BUS_ADDRESS in multiseat environment

2016-12-02 Thread Simon McVittie
On Fri, 02 Dec 2016 at 13:58:01 +0530, Mohan R wrote:
> Let say if a user already have a session(session0) in a seat (customseat0) and
> he want to start another session in another seat (customseat1).

Does this mean your user is trying to be physically present in two places
at the same time? How is this a useful thing to do? :-)

> Is there any way to make pam_systemd provides uniq DBUS_SESSION_BUS_ADDRESS 
> for
> every session (may be unix:path=$XDG_RUNTIME_DIR/$XDG_SESSION_ID/bus)? or is
> there any way to ask 'systemd --user' to provide different
> DBUS_SESSION_BUS_ADDRESS to the childs?

More background on user-sessions in general:
https://lists.freedesktop.org/archives/systemd-devel/2015-January/027711.html

pam_systemd does not do this unless you have configured dbus-daemon
to provide one bus per logind user-session
(./configure --enable-user-session), which is not the default.
Either you or your OS vendor have explicitly chosen this model: if that
doesn't match your requirements, you need to revert this choice.

If you require multiple D-Bus sessions per logind user-session, you must
either configure dbus without --enable-user-session (the default is
equivalent to --disable-user-session), or mask or remove the
dbus.service and dbus.socket systemd user units that are installed
by enabling that option (/usr/lib/systemd/dbus.*).

The user-session support in dbus is designed to be easy to enable or
disable by adding/removing packages, if your OS vendor packages it
suitably. For example, in Debian (including derivatives like Ubuntu),
/usr/lib/systemd/dbus.* are packaged separately in the dbus-user-session
package, so you can remove that package to go back to the older model.

If your OS vendor has not packaged dbus like that, perhaps ask them to
look at how it's done in Debian? Or if they have deliberately chosen
not to support multiple D-Bus sessions per logind user-session, then
that OS distribution is not suitable for your requirements, and you
need to change either your requirements or your OS distribution.

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


Re: [systemd-devel] question regarding DBUS_SESSION_BUS_ADDRESS in multiseat environment

2016-12-02 Thread Mantas Mikulėnas
On Fri, Dec 2, 2016 at 10:28 AM, Mohan R  wrote:

> Hi,
>
> I'm working on a display-manager for a multiseat environment. Here is how
> we use logind
>
> 1. create new seat through udev
> 2. we set the XDG_SEAT in pamenv before calling pam_open_session()
> 3. we take XDG_SESSION_ID, XDG_RUNTIME_DIR and DBUS_SESSION_BUS_ADDRESS
> from pam_systemd
>
> Let say if a user already have a session(session0) in a seat (customseat0)
> and he want to start another session in another seat (customseat1). Our
> display manager would get the same DBUS_SESSION_BUS_ADDRESS from
> pam_systemd for session1.
>
> As we cannot use the same address for two sessions, we have to start
> dbus-session manually. Using the address provided by dbus-session as
> DBUS_SESSION_BUS_ADDRESS, we then proceed with starting gnome-keyring and
> gnome-session.
>
> Problem is, processes forked by 'systemd --user' will have
> DBUS_SESSION_BUS_ADDRESS="unix:path=$XDG_RUNTIME_DIR/bus" but processes
> forked by gnome-session will have DBUS_SESSION_BUS_ADDRESS=$
> DBUS_SESSION_PROVIDED_ADDRESS.
>
> Is there any way to make pam_systemd provides uniq
> DBUS_SESSION_BUS_ADDRESS for every session (may be
> unix:path=$XDG_RUNTIME_DIR/$XDG_SESSION_ID/bus)? or is there any way to
> ask 'systemd --user' to provide different DBUS_SESSION_BUS_ADDRESS to the
> childs?
>

No, only one graphical session at a time is supported. While you can start
additional sessions using `dbus-run-session` or the old `dbus-launch` (and
have them run independently, "traditional way"), systemd --user will only
ever use the main user bus.

Also, if you made systemd specify different bus envvars for different
services, you wouldn't be able to start the same service for *both*
sessions at once...

(*Technically,* I suppose it would be possible to make logind start
per-session instances of --user and so on and so on, but as it is nothing
like that is supported.)

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


Re: [systemd-devel] Question regarding systemd behavior during shutdown

2016-11-03 Thread Lennart Poettering
On Thu, 03.11.16 14:01, svk (shreyas...@gmail.com) wrote:

> Hi,
> I have a question regarding systemd behavior during shutdown.
> 
> I am using systemd 219 on a Linux 4.1 kernel(custom distribution). When I
> issue a "shutdown" command I observe something unusual :-

219 is really old, and the behaviour regarding the shutdown
transaction has changed a bit in the past. Any chance you can verify
this with something recent before we look into this?

Thanks,

Lennart

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


Re: [systemd-devel] Question on service related notifications

2016-09-25 Thread Mantas Mikulėnas
On Sun, Sep 25, 2016 at 8:04 AM, Pathangi Janardhanan 
wrote:

> Hi,
>
>  I would like to monitor for systemd related service notifications (for
> e.g. service started, service ready, service stopped or service failed etc.)
>
>  I am trying to look through the sd-bus notification, and was looking at
> the org.freedesktop.systemd1.manager and the subscribe method? Is this
> the method to be used for receiving this type of notifications, and if I
> use this would that program receive the correspodning notification through
> the UnitNew() and unitremoved(0 signals?
>

Close, but you'll probably want the Job{Added,Removed} and PropertyChanged
signals instead.

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


Re: [systemd-devel] Question about what systemd-udevd will do for a new scsi partition

2016-08-10 Thread lhuang



On 08/11/2016 12:13 AM, Lennart Poettering wrote:

On Wed, 10.08.16 05:44, Luyao Huang (lhu...@redhat.com) wrote:


Dear list,

I met a problem that looks like systemd-udevd will make a new scsi disk 
partition (like /dev/sdb1)
disappear in a few time. This problem makes libvirt cannot lstat the new scsi 
disk for a period.
(you can check this link https://bugzilla.redhat.com/show_bug.cgi?id=1264719).
And we wrote a script to verify this problem and finally find if we stop 
systemd-udevd, this will not happen.

Could you please give me some help and tell me what systemd-udevd does to a new 
scsi disk partition
making scsi disk partition disappear in a few time? Thanks in advance for your 
reply.

udev only propagates kernel events, it does not make up events on its
own. Whenever a new device is reported by the kernel, it will acquire
some additional metadata for it and forward it to clients. Similar,
when a device vanishes it will propagate the event too, with some
additional metadata attached.

Note that udev is also not involved in the creation or removal of
device nodes anymore. it will adjuts access rights and ACLs on
devices, but not create or remove them anymore. That's done by the
kernel directly via devtmpfs.

Long story short: you need to check why the kernel makes the devices
disappear, udev is just the messenger here.


Hi Lennart,

Thanks for your quick reply and your reply is really helpful. I will 
have a try to debug kernel and see what kernel does for a new scsi disk 
partition.


Have a nice day !

BR,
Luyao

Lennart



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


Re: [systemd-devel] Question about what systemd-udevd will do for a new scsi partition

2016-08-10 Thread Lennart Poettering
On Wed, 10.08.16 05:44, Luyao Huang (lhu...@redhat.com) wrote:

> Dear list,
> 
> I met a problem that looks like systemd-udevd will make a new scsi disk 
> partition (like /dev/sdb1)
> disappear in a few time. This problem makes libvirt cannot lstat the new scsi 
> disk for a period.
> (you can check this link https://bugzilla.redhat.com/show_bug.cgi?id=1264719).
> And we wrote a script to verify this problem and finally find if we stop 
> systemd-udevd, this will not happen.
> 
> Could you please give me some help and tell me what systemd-udevd does to a 
> new scsi disk partition
> making scsi disk partition disappear in a few time? Thanks in advance for 
> your reply.

udev only propagates kernel events, it does not make up events on its
own. Whenever a new device is reported by the kernel, it will acquire
some additional metadata for it and forward it to clients. Similar,
when a device vanishes it will propagate the event too, with some
additional metadata attached.

Note that udev is also not involved in the creation or removal of
device nodes anymore. it will adjuts access rights and ACLs on
devices, but not create or remove them anymore. That's done by the
kernel directly via devtmpfs.

Long story short: you need to check why the kernel makes the devices
disappear, udev is just the messenger here.

Lennart

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


Re: [systemd-devel] Question about changing systemd target during boot

2016-08-01 Thread Kai Krakow
Am Mon, 1 Aug 2016 16:09:36 +0300
schrieb Svetoslav Iliev :

> Hi guys,
> 
> Thank you for the prompt reply and your valuable input. Just to let
> you know - I was able to do exactly what I intended. As it turns out
> my mistake was indeed creating contradiction between the WantedBy and
> After sections. Once I introduced a new "change.target" and adjusted
> my services accordingly I was able to isolate successfully either A
> or B targets during boot.
> 
> I also had to split the services in two: one main blocking of type 
> oneshot and one non-blocking of simple type just to switch the
> target. As it seems I cannot call systemctl isolate from onehost type
> of service.

Wouldn't it be easier to simply make your change.target the default
boot target, depending on network-online.target and a service to start
the target you need instead of isolate? Otherwise multi-user.target
starts services you are going to stop just a blink later by using
isolate.

> I just like to say that I followed this guide: 
> https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget where
> I quote "/Alternatively, you can change your service that needs the 
> network to be up, to include After=network-online.target and 
> Wants=network-online.target./"
> 
> Once again thanks all for the help.
> 
> ---
> BR,
> 
> Swetli
> 
> On 08/01/2016 03:38 PM, Andrei Borzenkov wrote:
> > On Mon, Aug 1, 2016 at 2:43 PM, Michael Chapman
> >  wrote:  
> >> On Mon, 1 Aug 2016, Andrei Borzenkov wrote:  
>  [...]  
>  [...]  
>  [...]  
>  [...]  
>  [...]  
>  [...]  
> >>
> >> I just checked the code, and it looks like systemd explicitly
> >> *skips* these default dependencies if they would create a loop. In
> >> target_add_default_dependencies:
> >>  
> > Yes, of course. It is also described in manual. But the question is
> > what user actually intended? It is more topic of good design.
> > ___
> > systemd-devel mailing list
> > systemd-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/systemd-devel  
> 
> 



-- 
Regards,
Kai

Replies to list-only preferred.

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


Re: [systemd-devel] Question about changing systemd target during boot

2016-08-01 Thread Svetoslav Iliev

Hi guys,

Thank you for the prompt reply and your valuable input. Just to let you 
know - I was able to do exactly what I intended. As it turns out my 
mistake was indeed creating contradiction between the WantedBy and After 
sections. Once I introduced a new "change.target" and adjusted my 
services accordingly I was able to isolate successfully either A or B 
targets during boot.


I also had to split the services in two: one main blocking of type 
oneshot and one non-blocking of simple type just to switch the target. 
As it seems I cannot call systemctl isolate from onehost type of service.


I just like to say that I followed this guide: 
https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget where I 
quote "/Alternatively, you can change your service that needs the 
network to be up, to include After=network-online.target and 
Wants=network-online.target./"


Once again thanks all for the help.

---
BR,

Swetli

On 08/01/2016 03:38 PM, Andrei Borzenkov wrote:

On Mon, Aug 1, 2016 at 2:43 PM, Michael Chapman  wrote:

On Mon, 1 Aug 2016, Andrei Borzenkov wrote:

On Mon, Aug 1, 2016 at 2:23 PM, Michael Chapman 
wrote:

On Mon, 1 Aug 2016, Andrei Borzenkov wrote:
[...]


So here goes what I've done:

1. Create a service and put it in the network-online.target:

/etc/systemd/system/change-target.service:
[Unit]
Description=Change Target
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
ExecStart=/tmp/script.sh
TimeoutSec=60s

[Install]
WantedBy=network-online.target


This unit have conflicting requirements - on one hand it is
After=network-online.target, OTOH WantedBy=network-online.target
implies Before=network-online.target.



I've seen this asserted on this list a few times, but as far as I can
tell
it isn't actually correct. After/Before are meant to be completely
orthogonal to Wants/Requires/etc., according to the documentation.


Unless DefaultDependencies= is set to no in either of releated units
or an explicit ordering dependency is already defined, target units
will implicitly complement all configured dependencies of type Wants=
or Requires= with dependencies of type After=.

man systemd.target


I just checked the code, and it looks like systemd explicitly *skips*
these default dependencies if they would create a loop. In
target_add_default_dependencies:


Yes, of course. It is also described in manual. But the question is
what user actually intended? It is more topic of good design.
___
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] Question about changing systemd target during boot

2016-08-01 Thread Andrei Borzenkov
On Mon, Aug 1, 2016 at 2:43 PM, Michael Chapman  wrote:
> On Mon, 1 Aug 2016, Andrei Borzenkov wrote:
>>
>> On Mon, Aug 1, 2016 at 2:23 PM, Michael Chapman 
>> wrote:
>>>
>>> On Mon, 1 Aug 2016, Andrei Borzenkov wrote:
>>> [...]
>
>
> So here goes what I've done:
>
> 1. Create a service and put it in the network-online.target:
>
> /etc/systemd/system/change-target.service:
> [Unit]
> Description=Change Target
> Wants=network-online.target
> After=network-online.target
>
> [Service]
> Type=oneshot
> ExecStart=/tmp/script.sh
> TimeoutSec=60s
>
> [Install]
> WantedBy=network-online.target
>

 This unit have conflicting requirements - on one hand it is
 After=network-online.target, OTOH WantedBy=network-online.target
 implies Before=network-online.target.
>>>
>>>
>>>
>>> I've seen this asserted on this list a few times, but as far as I can
>>> tell
>>> it isn't actually correct. After/Before are meant to be completely
>>> orthogonal to Wants/Requires/etc., according to the documentation.
>>>
>>
>> Unless DefaultDependencies= is set to no in either of releated units
>> or an explicit ordering dependency is already defined, target units
>> will implicitly complement all configured dependencies of type Wants=
>> or Requires= with dependencies of type After=.
>>
>> man systemd.target
>
>
> I just checked the code, and it looks like systemd explicitly *skips*
> these default dependencies if they would create a loop. In
> target_add_default_dependencies:
>

Yes, of course. It is also described in manual. But the question is
what user actually intended? It is more topic of good design.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Question about changing systemd target during boot

2016-08-01 Thread Michael Chapman

On Mon, 1 Aug 2016, Andrei Borzenkov wrote:

On Mon, Aug 1, 2016 at 2:23 PM, Michael Chapman  wrote:

On Mon, 1 Aug 2016, Andrei Borzenkov wrote:
[...]


So here goes what I've done:

1. Create a service and put it in the network-online.target:

/etc/systemd/system/change-target.service:
[Unit]
Description=Change Target
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
ExecStart=/tmp/script.sh
TimeoutSec=60s

[Install]
WantedBy=network-online.target



This unit have conflicting requirements - on one hand it is
After=network-online.target, OTOH WantedBy=network-online.target
implies Before=network-online.target.



I've seen this asserted on this list a few times, but as far as I can tell
it isn't actually correct. After/Before are meant to be completely
orthogonal to Wants/Requires/etc., according to the documentation.



Unless DefaultDependencies= is set to no in either of releated units
or an explicit ordering dependency is already defined, target units
will implicitly complement all configured dependencies of type Wants=
or Requires= with dependencies of type After=.

man systemd.target


I just checked the code, and it looks like systemd explicitly *skips*
these default dependencies if they would create a loop. In 
target_add_default_dependencies:


/* Imply ordering for requirement dependencies on target
 * units. Note that when the user created a contradicting
 * ordering manually we won't add anything in here to make
 * sure we don't create a loop. */

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


Re: [systemd-devel] Question about changing systemd target during boot

2016-08-01 Thread Michael Chapman

On Mon, 1 Aug 2016, Andrei Borzenkov wrote:
[...]

So here goes what I've done:

1. Create a service and put it in the network-online.target:

/etc/systemd/system/change-target.service:
[Unit]
Description=Change Target
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
ExecStart=/tmp/script.sh
TimeoutSec=60s

[Install]
WantedBy=network-online.target



This unit have conflicting requirements - on one hand it is
After=network-online.target, OTOH WantedBy=network-online.target
implies Before=network-online.target.


I've seen this asserted on this list a few times, but as far as I can tell 
it isn't actually correct. After/Before are meant to be completely 
orthogonal to Wants/Requires/etc., according to the documentation.


If A.service has:

  Wants=B.service
  Before=B.service

then any time you ask A.service to be started, systemd will add a job to 
start B.service... but it still ensures that A.service is started *before* 
B.service.


Is my understanding on this incorrect? I have been making use of this 
behaviour for quite some time, and as far as I can tell it has never 
failed.


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


Re: [systemd-devel] Question about changing systemd target during boot

2016-08-01 Thread Andrei Borzenkov
On Mon, Aug 1, 2016 at 2:23 PM, Michael Chapman  wrote:
> On Mon, 1 Aug 2016, Andrei Borzenkov wrote:
> [...]
>>>
>>> So here goes what I've done:
>>>
>>> 1. Create a service and put it in the network-online.target:
>>>
>>> /etc/systemd/system/change-target.service:
>>> [Unit]
>>> Description=Change Target
>>> Wants=network-online.target
>>> After=network-online.target
>>>
>>> [Service]
>>> Type=oneshot
>>> ExecStart=/tmp/script.sh
>>> TimeoutSec=60s
>>>
>>> [Install]
>>> WantedBy=network-online.target
>>>
>>
>> This unit have conflicting requirements - on one hand it is
>> After=network-online.target, OTOH WantedBy=network-online.target
>> implies Before=network-online.target.
>
>
> I've seen this asserted on this list a few times, but as far as I can tell
> it isn't actually correct. After/Before are meant to be completely
> orthogonal to Wants/Requires/etc., according to the documentation.
>

Unless DefaultDependencies= is set to no in either of releated units
or an explicit ordering dependency is already defined, target units
will implicitly complement all configured dependencies of type Wants=
or Requires= with dependencies of type After=.

man systemd.target

> If A.service has:
>
>   Wants=B.service
>   Before=B.service
>
> then any time you ask A.service to be started, systemd will add a job to
> start B.service... but it still ensures that A.service is started *before*
> B.service.
>
> Is my understanding on this incorrect? I have been making use of this
> behaviour for quite some time, and as far as I can tell it has never failed.
>
> - Michael
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Question about changing systemd target during boot

2016-08-01 Thread Andrei Borzenkov
On Mon, Aug 1, 2016 at 12:27 PM, Svetoslav Iliev  wrote:
> Hi all,
>
> I've been recently searching through internet for a possible solution for
> this but so far without success and I'm still not sure if it is even
> possible. Basically what I'm trying to do:
>
> During system boot, after the network-online target I want to execute a
> script which changes the current target ( or put simply just to boot in
> another target, not in the default multi-user.target).
>
> So here goes what I've done:
>
> 1. Create a service and put it in the network-online.target:
>
> /etc/systemd/system/change-target.service:
> [Unit]
> Description=Change Target
> Wants=network-online.target
> After=network-online.target
>
> [Service]
> Type=oneshot
> ExecStart=/tmp/script.sh
> TimeoutSec=60s
>
> [Install]
> WantedBy=network-online.target
>

This unit have conflicting requirements - on one hand it is
After=network-online.target, OTOH WantedBy=network-online.target
implies Before=network-online.target. Systemd breaks cycle here, but
what is correct?

Also network-online.target is intended to be passive, not pulling
anything, rather being pulled by other units.

> 2. Create two new targets:
> /etc/systemd/system/a.target:
> [Unit]
> Description=A Target
> Requires=multi-user.target
> After=multi-user.target
> AllowIsolate=yes
> Conflicts=b.target
>
> /etc/systemd/system/b.target:
> [Unit]
> Description=B Target
> Requires=multi-user.target
> After=multi-user.target
> AllowIsolate=yes
> Conflicts=a.target
>
> 3. The contents of script.sh
> blah blah: do some work and based on that do either
> systemctl isolate a.target || systemctl isolate b.target
>
> Note I've also edited the multi-user.target to depend on the the
> change-target.service by putting the latter in the former's wants and after
> sections. I've tried many things and every time it failed. The problem is
> that the systemd should "wait" for the execution of script.sh before
> continuing with the boot process.
>

This is virtually impossible currently. Nor is this requirement clear.
If systemd is as far as networking large part of startup sequence is
already processed. So how exactly you define units that can be started
before your switch and units that must wait?

> The question is - is what I'm trying to achieve even possible or systemd
> should boot in a certain target before changing to another one ? If possible
> please advise what I'm doing wrong since I'm pretty lost..
>
> ---
> BR,
>
> Swetli
>
>
> ___
> 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] Question about OnUnitInactiveSec= directive

2016-07-09 Thread Mikhail Kasimov

Seems, AccuracySec=1us parameter resolves this problem indeed:
=
Июл 09 10:55:30 linux-mk500 systemd[1]: Started VBA32 Anti-Virus Update 
Service.
Июл 09 11:00:30 linux-mk500 systemd[1]: Starting VBA32 Anti-Virus Update 
Service...


Июл 09 11:00:32 linux-mk500 systemd[1]: Started VBA32 Anti-Virus Update 
Service.
Июл 09 11:05:32 linux-mk500 systemd[1]: Starting VBA32 Anti-Virus Update 
Service...


Июл 09 11:05:35 linux-mk500 systemd[1]: Started VBA32 Anti-Virus Update 
Service.
Июл 09 11:10:35 linux-mk500 systemd[1]: Starting VBA32 Anti-Virus Update 
Service...

=

Haven't read about AccuracySec parameter in man-page carefully. :(

Resolved. Thank you again!

09.07.2016 08:23, Andrei Borzenkov пишет:

09.07.2016 01:37, Mikhail Kasimov пишет:

Hello!

Have a .timer service like:

==

[Unit]
Description=Runs VBA32 Update Hourly
Requires=timers.target

[Timer]
OnBootSec=2min
OnUnitInactiveSec=1h

[Install]
WantedBy=timers.target

==

to run vba32update.service in 1 hour after previous update-session is
over (OnUnitInactiveSec=1h).

 From man-page: "|OnUnitInactiveSec=| defines a timer relative to when
the unit the timer is activating was last deactivated."

Ok, here is log-snippet:
==
Июл 08 22:05:00 linux-mk500 systemd[1]: Starting VBA32 Anti-Virus Update
Service...
Июл 08 22:05:00 linux-mk500 vbacl[14768]: Vba32 console scanner update
process started
Июл 08 22:05:00 linux-mk500 vbacl[14768]: Reading configuration options
from ./vbacl.ini
Июл 08 22:05:00 linux-mk500 vbacl[14768]: Using direct connection for
update
Июл 08 22:05:02 linux-mk500 vbacl[14768]: Current dir is ./
Июл 08 22:05:02 linux-mk500 vbacl[14768]: Start update from
http://anti-virus.by/update
Июл 08 22:05:02 linux-mk500 vbacl[14768]: Receiving file list
Июл 08 22:05:02 linux-mk500 vbacl[14768]: File list received
Июл 08 22:05:02 linux-mk500 vbacl[14768]: Update is not needed
Июл 08 22:05:02 linux-mk500 systemd[1]: Started VBA32 Anti-Virus Update
Service.


...


We see 22:05:02 (end of update-session) --> 23:05:13 (start of next
update-session) --> 23:05:17 (end of update-session) --> 00:05:20 (start
of next update-session) --> 00:05:24 (end of update-session) -->
01:05:50 (start of next update-session) --> 01:05:55 (end of
update-session).

Question: Why time of new update-session is *not* equal to time of end
of previous update-session + 1h in section of seconds, e.g. 23:05:17 +1h
= 00:05:17; 00:05:24 + 1h = 01:05:24 and so on? Is here a way to reach
this precise coincidence?


Please check with "systemctl status" or "systemctl show" when unit was
actually deactivated. Also see "AccuracySec" timer parameter.

___
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] Question about OnUnitInactiveSec= directive

2016-07-08 Thread Andrei Borzenkov
09.07.2016 01:37, Mikhail Kasimov пишет:
> Hello!
> 
> Have a .timer service like:
> 
> ==
> 
> [Unit]
> Description=Runs VBA32 Update Hourly
> Requires=timers.target
> 
> [Timer]
> OnBootSec=2min
> OnUnitInactiveSec=1h
> 
> [Install]
> WantedBy=timers.target
> 
> ==
> 
> to run vba32update.service in 1 hour after previous update-session is
> over (OnUnitInactiveSec=1h).
> 
> From man-page: "|OnUnitInactiveSec=| defines a timer relative to when
> the unit the timer is activating was last deactivated."
> 
> Ok, here is log-snippet:
> ==
> Июл 08 22:05:00 linux-mk500 systemd[1]: Starting VBA32 Anti-Virus Update
> Service...
> Июл 08 22:05:00 linux-mk500 vbacl[14768]: Vba32 console scanner update
> process started
> Июл 08 22:05:00 linux-mk500 vbacl[14768]: Reading configuration options
> from ./vbacl.ini
> Июл 08 22:05:00 linux-mk500 vbacl[14768]: Using direct connection for
> update
> Июл 08 22:05:02 linux-mk500 vbacl[14768]: Current dir is ./
> Июл 08 22:05:02 linux-mk500 vbacl[14768]: Start update from
> http://anti-virus.by/update
> Июл 08 22:05:02 linux-mk500 vbacl[14768]: Receiving file list
> Июл 08 22:05:02 linux-mk500 vbacl[14768]: File list received
> Июл 08 22:05:02 linux-mk500 vbacl[14768]: Update is not needed
> Июл 08 22:05:02 linux-mk500 systemd[1]: Started VBA32 Anti-Virus Update
> Service.
> 
...

> 
> We see 22:05:02 (end of update-session) --> 23:05:13 (start of next
> update-session) --> 23:05:17 (end of update-session) --> 00:05:20 (start
> of next update-session) --> 00:05:24 (end of update-session) -->
> 01:05:50 (start of next update-session) --> 01:05:55 (end of
> update-session).
> 
> Question: Why time of new update-session is *not* equal to time of end
> of previous update-session + 1h in section of seconds, e.g. 23:05:17 +1h
> = 00:05:17; 00:05:24 + 1h = 01:05:24 and so on? Is here a way to reach
> this precise coincidence?
> 

Please check with "systemctl status" or "systemctl show" when unit was
actually deactivated. Also see "AccuracySec" timer parameter.

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


Re: [systemd-devel] question on special configuration case

2016-06-08 Thread Greg KH
On Wed, Jun 08, 2016 at 06:43:04AM +, Hebenstreit, Michael wrote:
> > Really?  No journal messages are getting created at all?  No users logging 
> > in/out?  What does strace show on those processes?
> 
> Yes, messages are created - but I'm not interested in them. Maybe a
> user logs in for a 6h job - that's already tracked by the cluster
> software. There are virtually no demons running, no changes to the
> hardware - so all those demons are doing are looking out for
> themselves. Not really productive

If messages are created, they have to go somewhere, to think that they
would be "free" is crazy :)

> > So you are hurting all 253 cores because you can't spare 1?
> 
> Situation is a bit more complex. I have 64 physical cores, with 4
> units each for integer operations and 2 floating point units. So
> essentially if I reserve one integer unit for the OS, due to cache
> hierarchies and other oddities, I essentially take down 4 cores. The
> applications typically scale best if they run on a power of 2 number
> of cores. 

You can still run the applications on the "non-reserved" core, it's just
that the kernel can't get access to any of the others.  So you only take
the hit of any potential wakeups and other kernel housekeeping on that
one core.

Again, try it, you might be pleasantly surprised as your workload is
_exactly_ what that feature was created for.  To ignore it without
testing seems bizarre to me.  If it doesn't work for you, then either
that kernel feature needs to be fixed, or maybe we can just rip it out,
so you need to tell the kernel developers about it.

> > Again, that's not the issue, you can't see the time the kernel is using to 
> > do its work, but it is there (interrupts, scheduling, housekeeping,
> etc.)
> 
> shouldn't that show up in the time for worker threads?

How do you account for interrupts, I/O, scheduler processing time, etc?
:)

> And I'm not arguing you are wrong. We should minimize that and if
> possible keep all OS on an extra core. That does not make my argument
> invalid those demons are doing nothing more than housekeeping
> themselves in a very complicated fashion and they are wasting
> resources. 

Again, I think you are wasting more resources than you realize just
because you can't see it :)

And as others have pointed out, turn off watchdogs and you should be
fine from a systemd point of view.

thanks,

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


Re: [systemd-devel] question on special configuration case

2016-06-08 Thread Simon McVittie
On 08/06/16 03:04, Hebenstreit, Michael wrote:
>> What processes are showing up in your count?  Perhaps it's just a bug that 
>> needs to be fixed.
> /bin/dbus-daemon
> /usr/lib/systemd/systemd-journald
> /usr/lib/systemd/systemd-logind

dbus-daemon will wake up when there are D-Bus messages to be delivered,
or when D-Bus-related data in /usr/share/dbus-1/ changes. If there is
nothing emitting D-Bus messages then it shouldn't normally wake up.

In dbus >= 1.10 you can run "dbus-monitor --system" as root, and you'll
see any D-Bus message that goes past. Unfortunately this use-case for
monitoring didn't really work in previous versions.

If you want it to stay off the majority of your CPU cores, Greg's
recommendation to set up CPU affinity seems wise. dbus-daemon is
single-threaded (or 2-threaded if SELinux and the audit subsystem are
active), so it will normally only run on one CPU at a time anyway.

-- 
Simon McVittie
Collabora Ltd. 

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


Re: [systemd-devel] question on special configuration case

2016-06-08 Thread Jóhann B . Guðmundsson

On 06/08/2016 06:51 AM, Hebenstreit, Michael wrote:


Thanks for this and the other suggestions!

So for starters we’ll disable logind and dbus, increase watchdogsec 
and see where the footprint is – before disabling journald if 
necessary in a next step.




You cannot disable journal but you can reduce it and the following 
should give the least amount of logging in all potential scenarios and 
usage ;)


Just create "/etc/systemd/journald.conf.d/10-hpc-tweaks.conf"which contains

[Journal]
Storage=none
MaxLevelConsole=emerg
MaxLevelStore=emerg
MaxLevelSyslog=emerg
MaxLevelKMsg=emerg
MaxLevelConsole=emerg
MaxLevelWall=emerg
TTYPath=/dev/null

Then restart the journal ( systemctl restart systemd-journald )

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


Re: [systemd-devel] question on special configuration case

2016-06-08 Thread Lennart Poettering
On Tue, 07.06.16 21:00, Greg KH (gre...@linuxfoundation.org) wrote:

> On Wed, Jun 08, 2016 at 02:04:48AM +, Hebenstreit, Michael wrote:
> > > What processes are showing up in your count?  Perhaps it's just a
> > > bug that needs to be fixed.
> > /bin/dbus-daemon
> > /usr/lib/systemd/systemd-journald
> > /usr/lib/systemd/systemd-logind
> > 
> > I understand from the previous mails those are necessary to make
> > systemd work - but here they are doing nothing more than talking to
> > each other!
> 
> Really?  No journal messages are getting created at all?  No users
> logging in/out?  What does strace show on those processes?

It's the "watchdog" logic most likely. i.e. systemd has a per-service
setting WatchdogSec=. If that's set the daemons have to ping back PID
1 in regular intervals, or otherwise are assumed hanging.

On top of that PID 1 actually talks to hw watchdogs, if there are any,
by default.

If both of that is turned off, then there should be zero wakeups
really...

Lennart

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


Re: [systemd-devel] question on special configuration case

2016-06-08 Thread Lennart Poettering
On Tue, 07.06.16 22:17, Hebenstreit, Michael (michael.hebenstr...@intel.com) 
wrote:

> Thanks for the answers 
> 
> > Well, there's no tracking of sessions anymore, i.e. polkit and all that 
> > stuff won't work anymore reasonably, and everything else that involves 
> > anything graphical and so on.
> 
> Nothing listed is in anyway used on our system as already laid out
> in the original mail. Your answer implies though there is no real
> security issue though (like sshd not working or being exploitable to
> gain access to other accounts) - is this correct?

Yes, that's correct.

> > If I were you I'd actually look what wakes up the system IRL
> > instead of just trying to blanket remove everything.  Can you
> > clarify how dbus-daemon, systemd-journald, systemd-logind,
> > systemd-udevd are causing issue/impacting in the above setup some
> > thing more than "I dont think we need it hence we want to disable
> > it".
> 
> The approach "if you do not need it, do not run it" works for this
> case pretty well. Systemd demons take up cycles without doing
> anything useful for us. We do not do any logging, we do not change
> the hardware during runtime - so no matter how little time those
> unit consumes, it impacts scalability. As explained this is not
> acceptable in our environment.

Well, they really shouldn't take up cycles when idle, except for the
watchdog stuff, which is easy to disable... It sounds like the much
better idea to track this down, and fix it in the individual case.

Lennart

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


Re: [systemd-devel] question on special configuration case

2016-06-08 Thread Hebenstreit, Michael
Thanks for this and the other suggestions!

So for starters we’ll disable logind and dbus, increase watchdogsec and see 
where the footprint is – before disabling journald if necessary in a next step.

Regards
Michael


From: Mantas Mikulėnas [mailto:graw...@gmail.com]
Sent: Wednesday, June 08, 2016 11:35 AM
To: Hebenstreit, Michael
Cc: Systemd
Subject: Re: [systemd-devel] question on special configuration case

This sounds like you could start by unsetting WatchdogSec= for those daemons. 
Other than the watchdog, they shouldn't be using any CPU unless explicitly 
contacted.
On Wed, Jun 8, 2016, 02:50 Hebenstreit, Michael 
<michael.hebenstr...@intel.com<mailto:michael.hebenstr...@intel.com>> wrote:
The base system is actually pretty large (currently 1200 packages) - I hate 
that myself. Still performance wise the packages are not the issue. The SSDs 
used can easily handle that, and library loads are only happening once at 
startup (where the difference van be measured, but if the runtime is 24h 
startup time of 1s are not an issue). Kernel is tweaked, but those changes are 
relatively small.

The single problem biggest problem is OS noise. Aka every cycle that the CPU(s) 
are working on anything but the application. This is caused by a  combination 
of "large number of nodes" and "tightly coupled job processes".

Our current (RH6) based system runs with a minimal number of demons, none of 
them taking up any CPU time unless they are used. Systemd process are not so 
well behaved. After a few hours of running they are already at a few seconds. 
On a single system - or systems working independent like server farms - that is 
not an issue. On our systems each second lost is multiplied by the number of 
nodes in the jobs (let's say 200, but it could also be up to 1 or more on 
large installations) due to tight coupling. If 3 demons use 1s a day each (and 
this is realistic on Xeon Phi Knights Landing systems), that's slowing down the 
performance by almost 1% (3 * 200 / 86400 = 0.7% to be exact). And - we do not 
gain anything from those demons after initial startup!

My worst experience with such issues was on a cluster that lost 20% application 
performance due to a badly configured crond demon. Now I do not expect systemd 
to have such a negative impact, but even 1%, or even 0.5% of expected loss are 
too much in our case.

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


Re: [systemd-devel] question on special configuration case

2016-06-08 Thread Hebenstreit, Michael
> Really?  No journal messages are getting created at all?  No users logging 
> in/out?  What does strace show on those processes?

Yes, messages are created - but I'm not interested in them. Maybe a user logs 
in for a 6h job - that's already tracked by the cluster software. There are 
virtually no demons running, no changes to the hardware - so all those demons 
are doing are looking out for themselves. Not really productive

> So you are hurting all 253 cores because you can't spare 1?

Situation is a bit more complex. I have 64 physical cores, with 4 units each 
for integer operations and 2 floating point units. So essentially if I reserve 
one integer unit for the OS, due to cache hierarchies and other oddities, I 
essentially take down 4 cores. The applications typically scale best if they 
run on a power of 2 number of cores. 

> Again, that's not the issue, you can't see the time the kernel is using to do 
> its work, but it is there (interrupts, scheduling, housekeeping,
etc.)

shouldn't that show up in the time for worker threads? And I'm not arguing you 
are wrong. We should minimize that and if possible keep all OS on an extra 
core. That does not make my argument invalid those demons are doing nothing 
more than housekeeping themselves in a very complicated fashion and they are 
wasting resources. 



-Original Message-
From: Greg KH [mailto:gre...@linuxfoundation.org] 
Sent: Wednesday, June 08, 2016 11:01 AM
To: Hebenstreit, Michael
Cc: Jóhann B. Guðmundsson; Lennart Poettering; 
systemd-devel@lists.freedesktop.org
Subject: Re: [systemd-devel] question on special configuration case

On Wed, Jun 08, 2016 at 02:04:48AM +, Hebenstreit, Michael wrote:
> > What processes are showing up in your count?  Perhaps it's just a 
> > bug that needs to be fixed.
> /bin/dbus-daemon
> /usr/lib/systemd/systemd-journald
> /usr/lib/systemd/systemd-logind
> 
> I understand from the previous mails those are necessary to make 
> systemd work - but here they are doing nothing more than talking to 
> each other!

Really?  No journal messages are getting created at all?  No users logging 
in/out?  What does strace show on those processes?

> > That what "most" other system designers in your situation do :)
> Unfortunately I cannot reserve a CPU for OS - I'd like to, but the app 
> developers insist to use all 254 cores available

So you are hurting all 253 cores because you can't spare 1?  If you do the math 
I think you will find you will get increased throughput.  But what do I know... 
:)

> > Your kernel is eating more CPU time than those 1s numbers, why you 
> > aren't complaining about that seems strange to me :)
> I also check kernel - last time I look on RH6 all kernel threads 
> taking up clock ticks were actually doing work ^^ No time yet to do 
> the same on RH7 kernel

Again, that's not the issue, you can't see the time the kernel is using to do 
its work, but it is there (interrupts, scheduling, housekeeping,
etc.)  So get it out of the way entirely and see how much faster your 
application runs without it even present on those cpus, if you really have cpu 
bound processes.  That's what the feature was made for, people in your 
situation, to ignore it and try to go after something else seems very strange 
to me.

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


Re: [systemd-devel] question on special configuration case

2016-06-07 Thread Mantas Mikulėnas
This sounds like you could start by unsetting WatchdogSec= for those
daemons. Other than the watchdog, they shouldn't be using any CPU unless
explicitly contacted.

On Wed, Jun 8, 2016, 02:50 Hebenstreit, Michael <
michael.hebenstr...@intel.com> wrote:

> The base system is actually pretty large (currently 1200 packages) - I
> hate that myself. Still performance wise the packages are not the issue.
> The SSDs used can easily handle that, and library loads are only happening
> once at startup (where the difference van be measured, but if the runtime
> is 24h startup time of 1s are not an issue). Kernel is tweaked, but those
> changes are relatively small.
>
> The single problem biggest problem is OS noise. Aka every cycle that the
> CPU(s) are working on anything but the application. This is caused by a
> combination of "large number of nodes" and "tightly coupled job processes".
>
> Our current (RH6) based system runs with a minimal number of demons, none
> of them taking up any CPU time unless they are used. Systemd process are
> not so well behaved. After a few hours of running they are already at a few
> seconds. On a single system - or systems working independent like server
> farms - that is not an issue. On our systems each second lost is multiplied
> by the number of nodes in the jobs (let's say 200, but it could also be up
> to 1 or more on large installations) due to tight coupling. If 3 demons
> use 1s a day each (and this is realistic on Xeon Phi Knights Landing
> systems), that's slowing down the performance by almost 1% (3 * 200 / 86400
> = 0.7% to be exact). And - we do not gain anything from those demons after
> initial startup!
>
> My worst experience with such issues was on a cluster that lost 20%
> application performance due to a badly configured crond demon. Now I do not
> expect systemd to have such a negative impact, but even 1%, or even 0.5% of
> expected loss are too much in our case.
>
>
> -Original Message-
> From: Jóhann B. Guðmundsson [mailto:johan...@gmail.com]
> Sent: Wednesday, June 08, 2016 6:10 AM
> To: Hebenstreit, Michael; Lennart Poettering
> Cc: systemd-devel@lists.freedesktop.org
> Subject: Re: [systemd-devel] question on special configuration case
>
> On 06/07/2016 10:17 PM, Hebenstreit, Michael wrote:
>
> > I understand this usage model cannot be compared to laptops or web
> > servers. But basically you are saying systemd is not usable for our
> > High Performance Computing usage case and I might better off by
> > replacing it with sysinitV. I was hoping for some simpler solution,
> > but if it's not possible then that's life. Will certainly make an
> > interesting topic at HPC conferences :P
>
> I personally would be interesting comparing your legacy sysv init setup to
> an systemd one since systemd is widely deployed on embedded devices with
> minimal build ( systemd, udevd and journald ) where systemd footprint and
> resource usage has been significantly reduced.
>
> Given that I have pretty much crawled in the entire mud bath that makes up
> the core/baseOS layer in Fedora ( which RHEL and it's clone derive from )
> when I was working on integrating systemd in the distribution I'm also
> interesting how you plan on making a minimal targeted base image which
> installs and uses just what you need from that ( dependency ) mess without
> having to rebuild those components first. ( I would think systemd
> "tweaking" came after you had solved that problem first along with
> rebuilding the kernel if your plan is to use just what you need ).
>
> JBG
> ___
> 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] question on special configuration case

2016-06-07 Thread Andrew Thompson
On Tue, Jun 7, 2016 at 7:04 PM, Hebenstreit, Michael
 wrote:
>> That what "most" other system designers in your situation do :)
> Unfortunately I cannot reserve a CPU for OS - I'd like to, but the app 
> developers insist to use all 254 cores available

Tough situation. Use Forth, it's the only way, my friend.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


  1   2   3   >