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


[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

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


[systemd-devel] question about poweroff issue

2020-02-26 Thread jay.bur...@fujitsu.com



-Original Message-
From: systemd-devel  On Behalf Of 
systemd-devel-requ...@lists.freedesktop.org
Sent: Wednesday, February 26, 2020 6:00 AM
To: systemd-devel@lists.freedesktop.org
Subject: systemd-devel Digest, Vol 118, Issue 15

Send systemd-devel mailing list submissions to
systemd-devel@lists.freedesktop.org

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
or, via email, send a message with subject or body 'help' to
systemd-devel-requ...@lists.freedesktop.org

You can reach the person managing the list at
systemd-devel-ow...@lists.freedesktop.org

When replying, please edit your Subject line so it is more specific than "Re: 
Contents of systemd-devel digest..."


Today's Topics:

   1.  question about a poweroff issue (piliu)
   2.  Antw: [EXT] Infinite loop at startup on var fsck failure
  (Ulrich Windl)
   3. Re:  Antw: [EXT] Infinite loop at startup on var fsck failure
  (Michael Biebl)
   4.  Antw: Re: Antw: [EXT] Infinite loop at startup on var fsck
  failure (Ulrich Windl)
   5.  Read-only /etc, machine-id with an overlay - journald
  failing (Andreas Kempe)


--

Message: 1
Date: Wed, 26 Feb 2020 13:50:55 +0800
From: piliu 
To: SystemD Devel 
Subject: [systemd-devel] question about a poweroff issue
Message-ID: 
Content-Type: text/plain; charset=utf-8

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.

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?

Any suggestion?

Thanks,
Pingfan

There has been discussion on how systemd should behave if multiple shutdowns 
are received. I for one think the first
shutdown received should be honored through to completion. I have submitted a 
pull request that does exactly that.
It is under review and not accepted yet, but it is out there. It would hide the 
issue you are seeing but then again you are
shutting down.

https://github.com/systemd/systemd/pull/14945

-Jay



--

Message: 2
Date: Wed, 26 Feb 2020 10:05:21 +0100
From: "Ulrich Windl" 
To: "systemd-devel@lists.freedesktop.org"
, 
Subject: [systemd-devel] Antw: [EXT] Infinite loop at startup on

[systemd-devel] question about a poweroff issue

2020-02-25 Thread piliu
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.

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?

Any suggestion?

Thanks,
Pingfan

___
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


[systemd-devel] Question on Before=

2019-02-02 Thread 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?

tia,

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


[systemd-devel] Question about WATCHDOG

2019-01-11 Thread Sietse van Zanen
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?

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


[systemd-devel] Question about hardware watchdog

2018-11-05 Thread Liu, Shuang (ADITG/ESM)
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.

Please correct me if I am wrong.
Thanks.

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


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

2018-08-01 Thread Francis Moreau
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" ?

Thanks.
-- 
Francis
___
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


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

2018-03-23 Thread Brian J. Murrell
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?

That doesn't seem to be the case on my system:

Mar 23 09:44:03 server.interlinx.bc.ca systemd[1]: Reached target User and 
Group Name Lookups.
Mar 23 09:44:03 server.interlinx.bc.ca systemd[1]: Starting User and Group Name 
Lookups.
Mar 23 09:47:35 server.interlinx.bc.ca systemd[1]: Starting Berkeley Internet 
Name Domain (DNS) with native PKCS#11...
Mar 23 09:47:42 server.interlinx.bc.ca systemd[1]: Started Berkeley Internet 
Name Domain (DNS) with native PKCS#11.

Am I misunderstanding what systemd is trying to tell me above?  Is it
not saying that the nss-lookup.target was reached (and therefore
services that depend on it can go ahead) before the DNS service was
actually even started?

If I am misunderstanding, is there a better way to understand the order
that units were started in than looking at the journal?

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


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

2018-01-25 Thread Bao Nguyen
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


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


[systemd-devel] question about socket activation

2017-12-29 Thread eshark
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.___
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


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

2017-11-29 Thread Vengatesh R
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

The information in this e-mail and any attachments is confidential and may be 
legally privileged. It is intended solely for the addressee or addressees. Any 
use or disclosure of the contents of this e-mail/attachments by a not intended 
recipient is unauthorized and may be unlawful. If you have received this e-mail 
in error please notify the sender. Please note that any views or opinions 
presented in this e-mail are solely those of the author and do not necessarily 
represent those of TEMENOS. We recommend that you check this e-mail and any 
attachments against viruses. TEMENOS accepts no liability for any damage caused 
by any malicious code or virus transmitted by this e-mail.
___
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


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

2017-11-27 Thread 千葉幹正
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


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


[systemd-devel] Question

2017-11-25 Thread 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.

Thanks
Peter
-- 
Hartelijke Groet
Peter
06-45108537
___
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


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

2017-11-24 Thread Bao Nguyen
Hello everyone,

I would like to have a question regarding to the building dependency and
cycle dependency handling on systemd-228. In my system, I have some socket
and service files, it has a cycle on socket target, when I run on
system-228, systemd-228 throws

[   40.358582] systemd[1]: Set hostname to .
[   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
[ SKIP ] Ordering cycle found, skipping My Telnet Server Socket on port 5101
[ SKIP ] Ordering cycle found, skipping My Telnet Server Socket on port 5010
[ SKIP ] Ordering cycle found, skipping My Telnet Server Socket on port 5111
[ SKIP ] Ordering cycle found, skipping asi-vsftpd-MyIO_2.socket
[ SKIP ] Ordering cycle found, skipping My Telnet Server Socket on port 5110
[ SKIP ] Ordering cycle found, skipping My Telnet Server Socket on port 5002
[ SKIP ] Ordering cycle found, skipping My Telnet Server Socket on port 5100
[ SKIP ] Ordering cycle found, skipping Remo...ell Facilities Activation
Socket
[ SKIP ] Ordering cycle found, skipping My Telnet Server Socket on port 5011
[ SKIP ] Ordering cycle found, skipping My sshd target


It said that there is an ordering on the sockets.target, then break the
cycle and SKIP randomly starting other service => the system cannot start.
However I did not meet the same issue on systemd-210 with the same my
services and sockets. Systemd-210 does not break and skip, and my system
can start well.

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

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

Many thanks for your support,
Best regards,
Naru
___
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


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

2017-09-26 Thread matthew

  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


[systemd-devel] [Question] timezones in timers

2017-09-04 Thread Ivan Kurnosov
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`

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


[systemd-devel] question about system reboot and shutdown

2017-08-08 Thread Marek Floriańczyk
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.

In previous version of init system I checked $runlevel variable but now I'm 
doing some "grep" commands according to this post

https://stackoverflow.com/questions/25166085/how-can-a-systemd-controlled-service-distinguish-between-shutdown-and-reboot

and sometimes my method doesn't work. Either in  /usr/bin/systemctl list-jobs 
there is sometimes reboot and shutdown process present, or my microupsd 
process gets killed before it sends data to the MicroUPS device over Rs232.

What would be the proper way to distinguish between system is going down for 
reboot and for 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 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


[systemd-devel] Question about systemd-firstboot

2017-03-09 Thread Francis Moreau
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 ?

Thanks.
-- 
Francis
___
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


[systemd-devel] question regarding DBUS_SESSION_BUS_ADDRESS in multiseat environment

2016-12-02 Thread Mohan R
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?

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


[systemd-devel] Question regarding systemd behavior during shutdown

2016-11-03 Thread svk
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 :-

If a process managed by a systemd unit file with "Restart=always" exits
prior to receiving a SIGTERM, systemd attempts to restart the service.
However, since the system is shutting down, systemd detects a conflict with
shutdown.target, and declares that the service had entered "failed" state.
Wouldn't it be cleaner to detect this before attempting to execute the
restart job? A service voluntarily exiting during shutdown should not be
considered as a failure.

Sample journal logs with detailed output enabled:-

Sep 22 22:59:34 re0 systemd[1]: foo.service holdoff time over, scheduling
restart.

33937 Sep 22 22:59:34 re0 systemd[1]: Trying to enqueue job
foo.service/restart/fail

Sep 22 22:59:34 re0 systemd[1]: Requested transaction contradicts existing
jobs: Transaction is destructive

Sep 22 22:59:34 re0 systemd[1]:foo.service failed to schedule restart job:
Transaction is destructive.

Sep 22 22:59:34 re0 systemd[1]: foo.service changed auto-restart -> failed
Thanks,
Shreyas
___
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


  1   2   3   4   >