[systemd-devel] Local system does not support BPF/cgroup based firewalling

[Nikos Chantziaras]

I'm getting these at startup:

systemd[1]: File /lib/systemd/system/systemd-journald.service:33 
configures an IP firewall (IPAddressDeny=any), but the local system does 
not support BPF/cgroup based firewalling.

systemd[1]: Proceeding WITHOUT firewalling in effect!
systemd[1]: File /lib/systemd/system/systemd-udevd.service:32 configures 
an IP firewall (IPAddressDeny=any), but the local system does not 
support BPF/cgroup based firewalling.

systemd[1]: Proceeding WITHOUT firewalling in effect!
systemd[1]: File /lib/systemd/system/systemd-logind.service:34 
configures an IP firewall (IPAddressDeny=any), but the local system does 
not support BPF/cgroup based firewalling.

systemd[1]: Proceeding WITHOUT firewalling in effect!

What do I need to make this work? I found this:

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

But CONFIG_BPF_SYSCALL is enabled and I still get that message.

This is on kernel 4.9.59 with systemd 235.

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

Re: [systemd-devel] list-units descriptions and trailing whitespace

[Mantas Mikulėnas]

On Fri, Oct 27, 2017 at 4:41 PM, Tom Matthews 
wrote:

> Good afternoon,
> Is there a good reason why list-units pads the description field out with
> trailing whitespace ?


Probably so that the line would be fully underlined; see
https://github.com/systemd/systemd/pull/6601

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

[systemd-devel] list-units descriptions and trailing whitespace

[Tom Matthews]

Good afternoon,
Is there a good reason why list-units pads the description field out with 
trailing whitespace ?


$ systemctl list-units | cat -vet | head -6
  UNIT  
 LOAD   ACTIVE SUB   DESCRIPTION

   $
  proc-sys-fs-binfmt_misc.automount 
 loaded active running   Arbitrary Executable File 
Formats File System Automount Point 
$
  sys-devices-pci:00-:00:02.0-backlight-acpi_video0.device  
 loaded active plugged   
/sys/devices/pci:00/:00:02.0/backlight/acpi_video0  
  $
  
sys-devices-pci:00-:00:14.0-usb1-1\x2d4-1\x2d4:1.0-host8-target8:0:0-8:0:0:0-block-sde-sde1.device
 loaded active plugged   IUM01-512MFHS bpool
   $
  
sys-devices-pci:00-:00:14.0-usb1-1\x2d4-1\x2d4:1.0-host8-target8:0:0-8:0:0:0-block-sde-sde2.device
 loaded active plugged   IUM01-512MFHS 2
   $
  
sys-devices-pci:00-:00:14.0-usb1-1\x2d4-1\x2d4:1.0-host8-target8:0:0-8:0:0:0-block-sde-sde9.device
 loaded active plugged   IUM01-512MFHS 9
   $


Here is what I’d rather be receiving, is there any particular reason for 
padding the description field with whitespace?

$ systemctl list-units | sed -E 's/\s+$//' | cat -vet | head -6
  UNIT  
 LOAD   ACTIVE SUB   DESCRIPTION$
  proc-sys-fs-binfmt_misc.automount 
 loaded active running   Arbitrary Executable File 
Formats File System Automount Point$
  sys-devices-pci:00-:00:02.0-backlight-acpi_video0.device  
 loaded active plugged   
/sys/devices/pci:00/:00:02.0/backlight/acpi_video0$
  
sys-devices-pci:00-:00:14.0-usb1-1\x2d4-1\x2d4:1.0-host8-target8:0:0-8:0:0:0-block-sde-sde1.device
 loaded active plugged   IUM01-512MFHS bpool$
  
sys-devices-pci:00-:00:14.0-usb1-1\x2d4-1\x2d4:1.0-host8-target8:0:0-8:0:0:0-block-sde-sde2.device
 loaded active plugged   IUM01-512MFHS 2$
  
sys-devices-pci:00-:00:14.0-usb1-1\x2d4-1\x2d4:1.0-host8-target8:0:0-8:0:0:0-block-sde-sde9.device
 loaded active plugged   IUM01-512MFHS 9$


Kind regards,
Tom Matthews
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemctl can't execute stop actually, when service is started by other way

[Silvio Knizek]

Am Dienstag, den 27.06.2017, 13:48 +0800 schrieb 清辰:
> for example: service nscd
> 1.execute: systemctl stop nscd.service
>   stop nscd process actually
> 2.execute: /usr/bin/nscd
>   start nscd by shell command
> 3.execute: systemctl status nscd.service
>   inactive(dead)
>   systemctl can't know nscd is running
> 4.excute: systemctl stop nscd.service
>   nscd process still exist, it seems that systemctl does not execute
> stop actually
> 
> 
> How can I stop nscd.service by systemctl when it is started not by
> systemctl?
> 
> 
> Why I need stop nscd.service by systemctl? 
> Because when linux reboot or shut down, linux will auto stop service
> by 'systemctl stop nscd.service'.
> If 'systemctl stop nscd.service' does not stop service actually, my
> service will exit abnormally. That may lead data loss in my service.
> 
> 
> Thank you very much

Hi,

you can't. Only services started by systemd are properly stopped by
systemd. Everything else will be killed during the last killing spree.
Also please keep in mind that processes you started on a shell might be
 killed as soon as the user logs out the shell belongs to. Or when the
users session is stopped.

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

Re: [systemd-devel] Scheduling unit at reboot.target and shutdown.target

[D.S. Ljungmark]

On 27/10/17 12:25, Lennart Poettering wrote:
> On Fr, 27.10.17 11:43, D.S. Ljungmark (spi...@aanstoot.se) wrote:
> 
>> So, I've got a piece of hardware I want to do a final handover to just
>> around reboot.target / shutdown.target
>>
>> This will then cause the entire CPU and hardware allocated to it to
>> actually drop power (and schedule re-power), so I don't want to do this
>> earlier.
>>
>>
>>
>> Is it simply to do:
>>
>> [Unit]
>> DefaultDependencies=no
>>
>> [Service]
>> ExecStart=/usr/bin/big-buck-bunny /dev/i2c-1
>> Type=oneshot
>>
>> [Install]
>> WantedBy=reboot.target
>>
>> or am I missing something here? ( Perhaps the fact that systemd has
>> already pivoted root to somewhere else?)
> 
> Well, the above is not the right way really.
> 
> 1. If you want to go for the unit option, it is definitely a better
>idea to define one that is started at boot (but has ExecStart=
>empty and only ExecStop= defined, and uses RemainAfterExit= to
>ensure that it stays active even without a process around). Only
>that way you can properly order your unit against other shutdown
>units.
> 
> 2. Doing this via a unit means your code is invoked during the first
>phase of shutdown, inside the usual dependency tree logic. I figure
>you actually want to do this later even, i.e. after all services
>are down, after systemd did its killing spree and umount spree and
>all that stuff. For that simply drop the binary/script of your
>choice in /usr/lib/systemd/system-shutdown/. All files in that dir
>that are marked executable are executed right before we'd return to
>the initrd/invoke the reboot() syscall. Also see:
>systemd-shutdown(8)
> 
> 3. Note that the scripts in /usr/lib/systemd/system-shutdown/ are
>invoked at a time where the root file system itself is still
>mounted. This means various weird storage daemons might still be
>pinned (think: root on mdraid/LVM/…). Hence, turning off power at
>that point is not fully safe nor correct either, except if you know
>your setup and know you don't have weird storage. If you want to
>cover this generic case too, then you have to use an initrd, make
>use of systemd's logic to transition back into the initrd at
>shutdown, and invoke what you want to invoke from there.
> 
> Lennart



Since this is an embedded case, we have fairly good control over what's
running and where.  For example, rootfs is not a problem as it's
squashfs, and shouldn't be degraded by rebooting.  As long as our
configuration/data partitions aren't mounted, we ought to be good.

And thank you for the pointer about /usr/lib/systemd/system-shutdown/
that indeed sounds a lot better for us.

ExecStop does indeed sound like the wrong solution as well, as mentioned
due to the ordering.


Thanks for the thorough explanation, much appreciated!

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

[systemd-devel] ???????????? ?????? ?????? [systemd-de vel] sys temctl can't execute stop actually,whenservice isstarted by other way

[????]

okay, thank you for your help very much.


--  --
??: Lennart Poettering 
: 2017??10??27?? 18:27
??:  <624001...@qq.com>
: Oliver Neukum , systemd-devel 

:  [systemd-devel] ?? ?? [systemd-de vel] sys temctl 
can't execute stop actually,whenservice isstarted by other way



On Fr, 27.10.17 18:25,  (624001...@qq.com) wrote:

> When executing 'service xxx restart', actually systemd will execute 'service 
> xxx start', and then 'service xxx stop'.
> But my restart action is different from stop action, can I customize my 
> 'restart'?

First of all, note that systemd does not actually provide a "service"
tool. It provides "systemctl", and your downstream distros map
"service" to "systemctl".

And no, in systemd we give the guarantee that restarts are equivalent
to stop+start, and you cannot customize 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] 回复： 回复： 回复： [systemd-de vel] systemctl can't execute stop actually,whenservice is started by other way

[Reindl Harald]

Am 27.10.2017 um 12:25 schrieb 清辰:
When executing 'service xxx restart', actually systemd will execute 
'service xxx start', and then 'service xxx stop'.
But my restart action is different from stop action, can I customize my 
'restart'?


no - fix the service

this sounds somehow as you have multiple things in a single service 
which should be splitted into several services with Before/After 
dependencies or even a own target

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

Re: [systemd-devel] 回复： 回复： [systemd-de vel] systemctl can't execute stop actually,whenservice is started by other way

[Reindl Harald]

Am 27.10.2017 um 11:53 schrieb 清辰:
Where is the 'service xxx status' result stored? Or can I change the 
service status manually, when start / stop the service outside of systemd


just don't start it outside systemd - yes it's really that easy
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Scheduling unit at reboot.target and shutdown.target

[Lennart Poettering]

On Fr, 27.10.17 11:43, D.S. Ljungmark (spi...@aanstoot.se) wrote:

> So, I've got a piece of hardware I want to do a final handover to just
> around reboot.target / shutdown.target
> 
> This will then cause the entire CPU and hardware allocated to it to
> actually drop power (and schedule re-power), so I don't want to do this
> earlier.
> 
> 
> 
> Is it simply to do:
> 
> [Unit]
> DefaultDependencies=no
> 
> [Service]
> ExecStart=/usr/bin/big-buck-bunny /dev/i2c-1
> Type=oneshot
> 
> [Install]
> WantedBy=reboot.target
>
> or am I missing something here? ( Perhaps the fact that systemd has
> already pivoted root to somewhere else?)

Well, the above is not the right way really.

1. If you want to go for the unit option, it is definitely a better
   idea to define one that is started at boot (but has ExecStart=
   empty and only ExecStop= defined, and uses RemainAfterExit= to
   ensure that it stays active even without a process around). Only
   that way you can properly order your unit against other shutdown
   units.

2. Doing this via a unit means your code is invoked during the first
   phase of shutdown, inside the usual dependency tree logic. I figure
   you actually want to do this later even, i.e. after all services
   are down, after systemd did its killing spree and umount spree and
   all that stuff. For that simply drop the binary/script of your
   choice in /usr/lib/systemd/system-shutdown/. All files in that dir
   that are marked executable are executed right before we'd return to
   the initrd/invoke the reboot() syscall. Also see:
   systemd-shutdown(8)

3. Note that the scripts in /usr/lib/systemd/system-shutdown/ are
   invoked at a time where the root file system itself is still
   mounted. This means various weird storage daemons might still be
   pinned (think: root on mdraid/LVM/…). Hence, turning off power at
   that point is not fully safe nor correct either, except if you know
   your setup and know you don't have weird storage. If you want to
   cover this generic case too, then you have to use an initrd, make
   use of systemd's logic to transition back into the initrd at
   shutdown, and invoke what you want to invoke from there.

Lennart

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

[systemd-devel] ?????? ?????? ?????? [systemd-de vel] systemctl can't execute stop actually,whenservice is started by other way

[????]

When executing 'service xxx restart', actually systemd will execute 'service 
xxx start', and then 'service xxx stop'.
But my restart action is different from stop action, can I customize my 
'restart'?




--  --
??: "Lennart Poettering"; 
: 2017??10??27??(??) 6:15
??: ""<624001...@qq.com>; 
: "Oliver Neukum"; 
"systemd-devel"; 
: Re: [systemd-devel] ?? ?? [systemd-de vel] systemctl can't 
execute stop actually,whenservice is started by other way



On Fr, 27.10.17 17:53,  (624001...@qq.com) wrote:

> Hi, 
> 
> 
> Where is the 'service xxx status' result stored? Or can I change the
> service status manually, when start / stop the service outside of
> systemd.

PID 1 maintains a per-service record in its internal memory. Only
PID 1 itself has write access to it.

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] 回复： 回复： 回复： [systemd-de vel] systemctl can't execute stop actually,whenservice is started by other way

[Lennart Poettering]

On Fr, 27.10.17 18:25, 清辰 (624001...@qq.com) wrote:

> When executing 'service xxx restart', actually systemd will execute 'service 
> xxx start', and then 'service xxx stop'.
> But my restart action is different from stop action, can I customize my 
> 'restart'?

First of all, note that systemd does not actually provide a "service"
tool. It provides "systemctl", and your downstream distros map
"service" to "systemctl".

And no, in systemd we give the guarantee that restarts are equivalent
to stop+start, and you cannot customize 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] Scheduling unit at reboot.target and shutdown.target

[Jérémy Rosen]

see man:bootup for the general architecture of shutdown and 
man:systemd-shutdown for how to add a script as the "ultimate phase" of 
the shutdown


doing it with services is tricky, your approch will make it be called at 
shutdown but you did not specify "when" during shutdown, so systemd 
might schedule it at any point


you could try to plug it in at the right place using some Before= and 
After= but if that command is the "real shutdown" command, i'd use the 
process described in systemd-shutdown



regards
Jérémy

On 27/10/2017 11:43, D.S. Ljungmark wrote:

So, I've got a piece of hardware I want to do a final handover to just
around reboot.target / shutdown.target

This will then cause the entire CPU and hardware allocated to it to
actually drop power (and schedule re-power), so I don't want to do this
earlier.



Is it simply to do:

[Unit]
DefaultDependencies=no

[Service]
ExecStart=/usr/bin/big-buck-bunny /dev/i2c-1
Type=oneshot

[Install]
WantedBy=reboot.target



or am I missing something here? ( Perhaps the fact that systemd has
already pivoted root to somewhere else?)

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


--
SMILE 

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


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

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

Twitter  Facebook 
 LinkedIn 
 Github 




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



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

Re: [systemd-devel] 回复： 回复： [systemd-de vel] systemctl can't execute stop actually,whenservice is started by other way

[Lennart Poettering]

On Fr, 27.10.17 17:53, 清辰 (624001...@qq.com) wrote:

> Hi, 
> 
> 
> Where is the 'service xxx status' result stored? Or can I change the
> service status manually, when start / stop the service outside of
> systemd.

PID 1 maintains a per-service record in its internal memory. Only
PID 1 itself has write access to it.

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] ?????? ?????? [systemd-de vel] systemctl can't execute stop actually,whenservice is started by other way

[????]

Hi, 


Where is the 'service xxx status' result stored? Or can I change the service 
status manually, when start / stop the service outside of systemd.


Thank you.




-- Original --
From: "Lennart Poettering"; 
Date: 2017??6??29??(??) 4:29
To: "Oliver Neukum"; 
Cc: ""<624001...@qq.com>; 
"systemd-devel"; 
Subject: Re: [systemd-devel] ?? ?? [systemd-de vel] systemctl can't 
execute stop actually,whenservice is started by other way



On Thu, 29.06.17 10:05, Oliver Neukum (oneu...@suse.com) wrote:

> Am Mittwoch, den 28.06.2017, 13:29 +0200 schrieb Lennart Poettering:
> > Well, it's a service manager. As such it keeps track of services,
> > knows when they are started and when they aren't. Why would it stop
> > services that aren't started?
> 
> Because you command it to do so.

Because things are technically designed that way. When systemd manages
services it does so ensuring it will get SIGCHLD events for them. it
will also run them in a cgroup, so that it can monitor its lifetime by
enumerating the cgroup's contents, and getting events from it.

Now, if you start stuff outside of systemd nothing of that is
available, so systemd wouldn#t know that is running, and it
couldn't properly stop anything because it can't get ahold of the
processes to terminate.

Lennart

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

[systemd-devel] Scheduling unit at reboot.target and shutdown.target

[D.S. Ljungmark]

So, I've got a piece of hardware I want to do a final handover to just
around reboot.target / shutdown.target

This will then cause the entire CPU and hardware allocated to it to
actually drop power (and schedule re-power), so I don't want to do this
earlier.



Is it simply to do:

[Unit]
DefaultDependencies=no

[Service]
ExecStart=/usr/bin/big-buck-bunny /dev/i2c-1
Type=oneshot

[Install]
WantedBy=reboot.target



or am I missing something here? ( Perhaps the fact that systemd has
already pivoted root to somewhere else?)

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