Re: [systemd-devel] Discrepancy in using dhclient b/w ubuntu 20.04 and ubuntu 16.04

2021-06-08 Thread Reindl Harald




Am 08.06.21 um 15:44 schrieb Aravindhan Krishnan:
With all due respect, it would be very helpful if you can be a little 
bit less snarky.


With all due respect, it would be very helpful not use reply-all and not 
convert each and every response to HTML



i don't get the bash-nonsense for a handful of lines (most of them doing
nothing at all) to begin with and given that there is no "Type=" in the
unit file you may read the docs and try the different types
 >> As per the man page 
(https://man7.org/linux/man-pages/man5/systemd.service.5.html 
), the 
default Type is simple if ExecStart is specified.


which means the prcoess is supposed to stay and not fork


i also don't get the trial-binary
why in the world don't you trhow away all that crap inlcuding the docker
container and start dhclient at your own from a trivial systemd-unit?
 >> As the name indicates it is a trial or minimalistic reproduction of 
the issue we are seeing. Actual issue: We have a binary, which starts, 
and stop dhclient on the interface on demand (Please don't come back 
complaining why you would need to start and stop dhclient on demand). In 
case the binary crashes for some unforeseen reason (which I had also 
mentioned in my initial mail. 


this is handeled by systemd pretty fine - but not with an intermediate 
script and/or binary between



why in the world don't you trhow away all that crap inlcuding the docker
container and start dhclient at your own from a trivial systemd-unit?
 >> Again, in a real-world scenario we support upto 1000+ vLANs. Running 
1000 different services for each of the dhclient could be too costly was 
our initial assessment and thus we ran "dhclient  -nw" from 
the parent process. If you feel systemd can handle such higher loads, 
without causing a high perf impact, it would be helpful as well


with your template service you have 1000 systemd services anyways but 
throw additional load on the machine with your monitoring binary which 
is monitored by systemd anyways


you gain nothing with all that wrappers
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Discrepancy in using dhclient b/w ubuntu 20.04 and ubuntu 16.04

2021-06-08 Thread Reindl Harald



Am 08.06.21 um 14:50 schrieb Aravindhan Krishnan:

Hi Reindl,

I have attached a minimalistic repro along with the codes of all the 
scripts, service files. I suppose Silvio was able to see the files. 


i don't get the bash-nonsense for a handful of lines (most of them doing 
nothing at all) to begin with and given that there is no "Type=" in the 
unit file you may read the docs and try the different types


i also don't get the trial-binary

why in the world don't you trhow away all that crap inlcuding the docker 
container and start dhclient at your own from a trivial systemd-unit?


it's impressive how many layers and helpers one can wrap around simple 
tasks but to gain what except troubles?


keep it simple!

On Mon, 7 Jun 2021 at 21:53, Reindl Harald <mailto:h.rei...@thelounge.net>> wrote:




Am 07.06.21 um 17:57 schrieb Aravindhan Krishnan:
 > Adding Raghav.
 >
 > And sorry the subject should have stated: Discrepancy in using
dhclient
 > b/w ubuntu 20.04 and ubuntu 16.04

and why didn't you fix it in your own reply?

to your problem:
you have a wild mix of docker, systemd-units and shellscripts but don't
provide the source of the scripts nor the systemd unit

overly complex for something that can be trivial as:

[root@srv-rhsoft:~]$ cat /etc/systemd/system/network-wan-dhcp.service
[Unit]
Description=Internet DHCP-Client

[Service]
Type=forking
ExecStart=/usr/sbin/dhclient -4 -q --no-pid --request-options
subnet-mask,broadcast-address,routers br-wan
PermissionsStartOnly=yes
SuccessExitStatus=80
Restart=always
RestartSec=5
ProtectSystem=strict
ProtectHome=yes
ReadWritePaths=-/var/lib/dhclient
PrivateTmp=yes
NoNewPrivileges=yes
ProtectKernelTunables=yes
ProtectKernelModules=yes
ProtectControlGroups=yes
MemoryDenyWriteExecute=yes
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE
CAP_NET_BROADCAST CAP_NET_RAW
LockPersonality=yes
PrivateDevices=yes
ProtectHostname=yes
RestrictNamespaces=yes
RestrictRealtime=yes
RestrictSUIDSGID=yes
ProtectClock=true
ProtectKernelLogs=true
UMask=077
SystemCallArchitectures=native
SystemCallFilter=@system-service @network-io @privileged
SystemCallFilter=~@aio @chown @clock @cpu-emulation @debug @keyring
@module @mount @obsolete @raw-io @reboot @resources @swap
InaccessiblePaths=-/boot
InaccessiblePaths=-/efi
InaccessiblePaths=-/root

 > On Mon, 7 Jun 2021 at 21:26, Aravindhan Krishnan
 > mailto:aravindhan...@gmail.com>
<mailto:aravindhan...@gmail.com <mailto:aravindhan...@gmail.com>>>
wrote:
 >
 >     Hi Folks,
 >
 >     I am finding anomalous behavior when I am trying to run dhclient
 >     process inside my docker container in vanilla Ubuntu 16.04
host. The
 >     service gets into "deactivating" state and is stuck forever.
In the
 >     mail I have attached a minimalistic reproduction of the issue
seen.
 >
 >     Working logic:
 >
 >       * There is a sample trial@.service script which invokes the
 >         `trial` binary with the option passed to the systemd
service via
 >         @ option
 >       * The valid options are sleep and dhclient_
 >       * The binary either invokes a long-lived sleep process or
dhclient
 >         process on the said interface_name based on the input
 >       * The binary then spawns `kill_trial.sh` script. The script
sleeps
 >         for 20 seconds and kills the parent `trial` binary. The kill
 >         signal is SIGKILL in the trial example. In the
real-world, this
 >         can be a SIGSEGV indicating a crash in the parent process.
 >       * If the trial binary was started for sleep process things work
 >         fine and service goes into "failed" state as expected
 >       * However, in case of dhclient, the service is stuck in
 >         "deactivating" state if the underlying host OS is Ubuntu
16.04.
 >         This works well if the host is running Ubuntu 20.04.
 >       * We have kept TimeoutStopSec to infinity, because in real-word
 >         deployments, the core collection post a crash takes
varying time
 >         depending on the memory config on the host.
 >
 >
 >     Steps to reproduce
 >     # tar -xf minimal_repro.tar -C minimal_repro/
 >     # cd minimal_repro/
 >     # docker build -t trial .
 >     # docker rm -f trial
 >     # docker run -it -d --net=host --privileged -v
 >     /sys/fs/cgroup:/sys/fs/cgroup:ro --name trial trial
 >     # docker exec -it trial bash
 >
 >     # systemctl start trial@d

Re: [systemd-devel] Discrepancy in using dhclient b/w ubuntu 20.04 and ubuntu 16.04

2021-06-07 Thread Reindl Harald



Am 07.06.21 um 17:57 schrieb Aravindhan Krishnan:

Adding Raghav.

And sorry the subject should have stated: Discrepancy in using dhclient 
b/w ubuntu 20.04 and ubuntu 16.04


and why didn't you fix it in your own reply?

to your problem:
you have a wild mix of docker, systemd-units and shellscripts but don't 
provide the source of the scripts nor the systemd unit


overly complex for something that can be trivial as:

[root@srv-rhsoft:~]$ cat /etc/systemd/system/network-wan-dhcp.service
[Unit]
Description=Internet DHCP-Client

[Service]
Type=forking
ExecStart=/usr/sbin/dhclient -4 -q --no-pid --request-options 
subnet-mask,broadcast-address,routers br-wan

PermissionsStartOnly=yes
SuccessExitStatus=80
Restart=always
RestartSec=5
ProtectSystem=strict
ProtectHome=yes
ReadWritePaths=-/var/lib/dhclient
PrivateTmp=yes
NoNewPrivileges=yes
ProtectKernelTunables=yes
ProtectKernelModules=yes
ProtectControlGroups=yes
MemoryDenyWriteExecute=yes
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE 
CAP_NET_BROADCAST CAP_NET_RAW

LockPersonality=yes
PrivateDevices=yes
ProtectHostname=yes
RestrictNamespaces=yes
RestrictRealtime=yes
RestrictSUIDSGID=yes
ProtectClock=true
ProtectKernelLogs=true
UMask=077
SystemCallArchitectures=native
SystemCallFilter=@system-service @network-io @privileged
SystemCallFilter=~@aio @chown @clock @cpu-emulation @debug @keyring 
@module @mount @obsolete @raw-io @reboot @resources @swap

InaccessiblePaths=-/boot
InaccessiblePaths=-/efi
InaccessiblePaths=-/root

On Mon, 7 Jun 2021 at 21:26, Aravindhan Krishnan 
mailto:aravindhan...@gmail.com>> wrote:


Hi Folks,

I am finding anomalous behavior when I am trying to run dhclient
process inside my docker container in vanilla Ubuntu 16.04 host. The
service gets into "deactivating" state and is stuck forever. In the
mail I have attached a minimalistic reproduction of the issue seen.

Working logic:

  * There is a sample trial@.service script which invokes the
`trial` binary with the option passed to the systemd service via
@ option
  * The valid options are sleep and dhclient_
  * The binary either invokes a long-lived sleep process or dhclient
process on the said interface_name based on the input
  * The binary then spawns `kill_trial.sh` script. The script sleeps
for 20 seconds and kills the parent `trial` binary. The kill
signal is SIGKILL in the trial example. In the real-world, this
can be a SIGSEGV indicating a crash in the parent process.
  * If the trial binary was started for sleep process things work
fine and service goes into "failed" state as expected
  * However, in case of dhclient, the service is stuck in
"deactivating" state if the underlying host OS is Ubuntu 16.04.
This works well if the host is running Ubuntu 20.04.
  * We have kept TimeoutStopSec to infinity, because in real-word
deployments, the core collection post a crash takes varying time
depending on the memory config on the host.


Steps to reproduce
# tar -xf minimal_repro.tar -C minimal_repro/
# cd minimal_repro/
# docker build -t trial .
# docker rm -f trial
# docker run -it -d --net=host --privileged -v
/sys/fs/cgroup:/sys/fs/cgroup:ro --name trial trial
# docker exec -it trial bash

# systemctl start trial@dhclient_eth1.service

# #Keep monitoring trial@dhclient_eth1.service -- issue should be
seen within 20-30 seconds on Ubuntu 16.04 host

# systemctl status trial@dhclient_eth1.service
● trial@dhclient_eth1.service - Trial
      Loaded: loaded (/etc/systemd/system/trial@.service; static;
vendor preset: enabled)
      Active: deactivating (stop-sigterm) (Result: signal) since Mon
2021-06-07 13:19:12 UTC; 1min 11s ago
     Process: 55 ExecStartPre=/bin/bash
/etc/systemd/system/trial_service_script.sh pre_start dhclient_eth1
(code=exited, status=0/SUCCESS)
     Process: 56 ExecStart=/bin/bash
/etc/systemd/system/trial_service_script.sh start dhclient_eth1
(code=killed, signal=KILL)
    Main PID: 56 (code=killed, signal=KILL)
       Tasks: 0 (limit: 38590)
      Memory: 588.0K
      CGroup:

/docker/903fca0cee1387b7c2113a36ee5efdb3a25edd1e60584fe5da5d0c5b5ffd8241/system.slice/system-trial.slice/trial@dhclient_eth1.service

# #NOTE: `Active: deactivating` -- in stuck state
# #Running `systemctl daemon-reload` forces the service to go to
failed state

# systemctl start trial@sleep.service

# #Keep monitoring trial@sleep.service -- would be killed in 20-30
seconds and goes into failed state as expected

# # systemctl status trial@sleep.service
● trial@sleep.service - Trial
      Loaded: loaded (/etc/systemd/system/trial@.service; static;
vendor preset: enabled)
      Active: failed (Result: signal) since Mon 2021-06-07 13:38:19
UTC; 21s ago
     Process: 113 

Re: [systemd-devel] Adding USB ID to hwdb/usb.ids

2021-06-02 Thread Reindl Harald




Am 02.06.21 um 16:39 schrieb Greg KH:

On Wed, Jun 02, 2021 at 03:48:41PM +0200, Reindl Harald wrote:



Am 02.06.21 um 07:04 schrieb Greg KH:

On Tue, Jun 01, 2021 at 09:38:37PM +0200, Michael Biebl wrote:

Am Di., 1. Juni 2021 um 20:44 Uhr schrieb Greg KH :

Works for me!  Make sure you are not trying to connect to 'https'.


No https? Why?


Because why would serving up text files about this topic requires https?


sorry, but we have 2021

* non-https is a warning in most browsers
* certifictes are free and automated these days
* https is not only about encryption

the point of https is

a) you are connected to the host you think
b) no manipulation on the wire

the encryption is not really the point


Then don't connect to the site if you don't want the data there


and how is that an argument given that the world is since 2018/2019 
practically https only?



Trying
to tell others what to do with their spare time in maintaining a
resource for all operating systems to use is a bit, well, you know...

greg "i am a horrible sysadmin" k-h
i better don't comment that given that certbot and tons of other 
solutions are there for years with no costs and 100% automation scaling 
for 1, 10 or 1000 vhosts

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


Re: [systemd-devel] Adding USB ID to hwdb/usb.ids

2021-06-02 Thread Reindl Harald




Am 02.06.21 um 07:04 schrieb Greg KH:

On Tue, Jun 01, 2021 at 09:38:37PM +0200, Michael Biebl wrote:

Am Di., 1. Juni 2021 um 20:44 Uhr schrieb Greg KH :

Works for me!  Make sure you are not trying to connect to 'https'.


No https? Why?


Because why would serving up text files about this topic requires https?


sorry, but we have 2021

* non-https is a warning in most browsers
* certifictes are free and automated these days
* https is not only about encryption

the point of https is

a) you are connected to the host you think
b) no manipulation on the wire

the encryption is not really the point
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] What causes "systemd-journald[3256]: Missed 127 kernel messages"

2021-06-01 Thread Reindl Harald




Am 01.06.21 um 12:42 schrieb Ulrich Windl:

Jun 01 12:33:10 h18 systemd-journald[3256]: Missed 134 kernel messages
Jun 01 12:33:10 h18 systemd-journald[3256]: Missed 139 kernel messages
Jun 01 12:33:10 h18 systemd-journald[3256]: Missed 413 kernel messages
Jun 01 12:33:10 h18 systemd-journald[3256]: Missed 134 kernel messages
Jun 01 12:33:10 h18 systemd-journald[3256]: Missed 138 kernel messages
Jun 01 12:33:10 h18 systemd-journald[3256]: Missed 195 kernel messages

A few questions:
1) What causes this?
2) How can systemd know how many messasges were missed?
3) Can I avoid that problem?

(systemd-234-24.82.1.x86_64 of SLES 15 SP2)


https://serverfault.com/questions/947556/systemd-journal-rate-limit
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] syscall-filters killing CGI after update to Fedora 33

2021-04-19 Thread Reindl Harald
it's the blacklisting of @resources which was as far as i remember a 
back-and-forth years ago between dist-upgrades


looks like systemd-246.13-1.fc33.x86_64 is covering too much here in 
case of blacklisting


Am 19.04.21 um 18:24 schrieb Reindl Harald:
after a long time using this SystemCallFilter perl-cgi with Fedora 33 
get killed - anyone an idea what changed that's obviously covered by the 
second line


SystemCallFilter=@system-service @network-io @privileged
SystemCallFilter=~@clock @cpu-emulation @debug @keyring @module @mount 
@obsolete @raw-io @reboot @resources @swap


either the blacklist of the new systemd version convers more than before 
or something changed in the perl stack


-

Process 7723 (mailgraph.cgi) of user 48 dumped core.#012#012Stack trace 
of thread 7723:#012#0  0x7f14be8e955d syscall (libc.so.6 + 
0xfc55d)#012#1  0x7f14be2959d2 g_thread_pool_new (libglib-2.0.so.0 + 
0x839d2)#012#2  0x7f14bde5ae5c g_task_get_type_once (libgio-2.0.so.0 
+ 0xabe5c)#012#3  0x7f14bde5af85 g_task_get_type (libgio-2.0.so.0 + 
0xabf85)#012#4  0x7f14bde5b09d g_task_new (libgio-2.0.so.0 + 
0xac09d)#012#5  0x7f14bdfd2c4e pango_fc_font_map_init 
(libpangoft2-1.0.so.0 + 0xac4e)#012#6  0x7f14be37db97 
g_type_create_instance (libgobject-2.0.so.0 + 0x39b97)#012#7 
0x7f14be3668c5 g_object_new_internal (libgobject-2.0.so.0 + 
0x228c5)#012#8  0x7f14be36769d g_object_new_with_properties 
(libgobject-2.0.so.0 + 0x2369d)#012#9  0x7f14be368311 g_object_new 
(libgobject-2.0.so.0 + 0x24311)#012#10 0x7f14be5f4d63 rrd_graph_init 
(librrd.so.8 + 0x1cd63)#012#11 0x7f14be5ef33a rrd_graph_v 
(librrd.so.8 + 0x1733a)#012#12 0x7f14be5f3653 rrd_graph (librrd.so.8 
+ 0x1b653)#012#13 0x7f14be639318 n/a (RRDs.so + 0x6318)#012#14 
0x7f14beac02b7 Perl_pp_entersub (libperl.so.5.32 + 0x1082b7)#012#15 
0x7f14beab8040 Perl_runops_standard (libperl.so.5.32 + 
0x100040)#012#16 0x7f14bea36c6c perl_run (libperl.so.5.32 + 
0x7ec6c)#012#17 0x556a6005934a main (perl + 0x134a)#012#18 
0x7f14be8151e2 __libc_start_main (libc.so.6 + 0x281e2)#012#19 
0x556a6005938e _start (perl + 0x138e)


Process 2374487 (smokeping_cgi) of user 48 dumped core.#012#012Stack 
trace of thread 2374487:#012#0  0x7f1b1850655d syscall (libc.so.6 + 
0xfc55d)#012#1  0x7f1b17e409d2 g_thread_pool_new (libglib-2.0.so.0 + 
0x839d2)#012#2  0x7f1b17a05e5c g_task_get_type_once (libgio-2.0.so.0 
+ 0xabe5c)#012#3  0x7f1b17a05f85 g_task_get_type (libgio-2.0.so.0 + 
0xabf85)#012#4  0x7f1b17a0609d g_task_new (libgio-2.0.so.0 + 
0xac09d)#012#5  0x7f1b17b7dc4e pango_fc_font_map_init 
(libpangoft2-1.0.so.0 + 0xac4e)#012#6  0x7f1b17f28b97 
g_type_create_instance (libgobject-2.0.so.0 + 0x39b97)#012#7 
0x7f1b17f118c5 g_object_new_internal (libgobject-2.0.so.0 + 
0x228c5)#012#8  0x7f1b17f1269d g_object_new_with_properties 
(libgobject-2.0.so.0 + 0x2369d)#012#9  0x7f1b17f13311 g_object_new 
(libgobject-2.0.so.0 + 0x24311)#012#10 0x7f1b1819fd63 rrd_graph_init 
(librrd.so.8 + 0x1cd63)#012#11 0x7f1b1819a33a rrd_graph_v 
(librrd.so.8 + 0x1733a)#012#12 0x7f1b1819e653 rrd_graph (librrd.so.8 
+ 0x1b653)#012#13 0x7f1b181fc318 n/a (RRDs.so + 0x6318)#012#14 
0x7f1b186dd2b7 Perl_pp_entersub (libperl.so.5.32 + 0x1082b7)#012#15 
0x7f1b186d5040 Perl_runops_standard (libperl.so.5.32 + 
0x100040)#012#16 0x7f1b18653c6c perl_run (libperl.so.5.32 + 
0x7ec6c)#012#17 0x5599a814734a main (perl + 0x134a)#012#18 
0x7f1b184321e2 __libc_start_main (libc.so.6 + 0x281e2)#012#19 
0x5599a814738e _start (perl + 0x138e)


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


[systemd-devel] syscvall-filters killing CGI after update to Fedora 33

2021-04-19 Thread Reindl Harald
after a long time using this SystemCallFilter perl-cgi with Fedora 33 
get killed - anyone an idea what changed that's obviously covered by the 
second line


SystemCallFilter=@system-service @network-io @privileged
SystemCallFilter=~@clock @cpu-emulation @debug @keyring @module @mount 
@obsolete @raw-io @reboot @resources @swap


either the blacklist of the new systemd version convers more than before 
or something changed in the perl stack


-

Process 7723 (mailgraph.cgi) of user 48 dumped core.#012#012Stack trace 
of thread 7723:#012#0  0x7f14be8e955d syscall (libc.so.6 + 
0xfc55d)#012#1  0x7f14be2959d2 g_thread_pool_new (libglib-2.0.so.0 + 
0x839d2)#012#2  0x7f14bde5ae5c g_task_get_type_once (libgio-2.0.so.0 
+ 0xabe5c)#012#3  0x7f14bde5af85 g_task_get_type (libgio-2.0.so.0 + 
0xabf85)#012#4  0x7f14bde5b09d g_task_new (libgio-2.0.so.0 + 
0xac09d)#012#5  0x7f14bdfd2c4e pango_fc_font_map_init 
(libpangoft2-1.0.so.0 + 0xac4e)#012#6  0x7f14be37db97 
g_type_create_instance (libgobject-2.0.so.0 + 0x39b97)#012#7 
0x7f14be3668c5 g_object_new_internal (libgobject-2.0.so.0 + 
0x228c5)#012#8  0x7f14be36769d g_object_new_with_properties 
(libgobject-2.0.so.0 + 0x2369d)#012#9  0x7f14be368311 g_object_new 
(libgobject-2.0.so.0 + 0x24311)#012#10 0x7f14be5f4d63 rrd_graph_init 
(librrd.so.8 + 0x1cd63)#012#11 0x7f14be5ef33a rrd_graph_v 
(librrd.so.8 + 0x1733a)#012#12 0x7f14be5f3653 rrd_graph (librrd.so.8 
+ 0x1b653)#012#13 0x7f14be639318 n/a (RRDs.so + 0x6318)#012#14 
0x7f14beac02b7 Perl_pp_entersub (libperl.so.5.32 + 0x1082b7)#012#15 
0x7f14beab8040 Perl_runops_standard (libperl.so.5.32 + 
0x100040)#012#16 0x7f14bea36c6c perl_run (libperl.so.5.32 + 
0x7ec6c)#012#17 0x556a6005934a main (perl + 0x134a)#012#18 
0x7f14be8151e2 __libc_start_main (libc.so.6 + 0x281e2)#012#19 
0x556a6005938e _start (perl + 0x138e)


Process 2374487 (smokeping_cgi) of user 48 dumped core.#012#012Stack 
trace of thread 2374487:#012#0  0x7f1b1850655d syscall (libc.so.6 + 
0xfc55d)#012#1  0x7f1b17e409d2 g_thread_pool_new (libglib-2.0.so.0 + 
0x839d2)#012#2  0x7f1b17a05e5c g_task_get_type_once (libgio-2.0.so.0 
+ 0xabe5c)#012#3  0x7f1b17a05f85 g_task_get_type (libgio-2.0.so.0 + 
0xabf85)#012#4  0x7f1b17a0609d g_task_new (libgio-2.0.so.0 + 
0xac09d)#012#5  0x7f1b17b7dc4e pango_fc_font_map_init 
(libpangoft2-1.0.so.0 + 0xac4e)#012#6  0x7f1b17f28b97 
g_type_create_instance (libgobject-2.0.so.0 + 0x39b97)#012#7 
0x7f1b17f118c5 g_object_new_internal (libgobject-2.0.so.0 + 
0x228c5)#012#8  0x7f1b17f1269d g_object_new_with_properties 
(libgobject-2.0.so.0 + 0x2369d)#012#9  0x7f1b17f13311 g_object_new 
(libgobject-2.0.so.0 + 0x24311)#012#10 0x7f1b1819fd63 rrd_graph_init 
(librrd.so.8 + 0x1cd63)#012#11 0x7f1b1819a33a rrd_graph_v 
(librrd.so.8 + 0x1733a)#012#12 0x7f1b1819e653 rrd_graph (librrd.so.8 
+ 0x1b653)#012#13 0x7f1b181fc318 n/a (RRDs.so + 0x6318)#012#14 
0x7f1b186dd2b7 Perl_pp_entersub (libperl.so.5.32 + 0x1082b7)#012#15 
0x7f1b186d5040 Perl_runops_standard (libperl.so.5.32 + 
0x100040)#012#16 0x7f1b18653c6c perl_run (libperl.so.5.32 + 
0x7ec6c)#012#17 0x5599a814734a main (perl + 0x134a)#012#18 
0x7f1b184321e2 __libc_start_main (libc.so.6 + 0x281e2)#012#19 
0x5599a814738e _start (perl + 0x138e)

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


Re: [systemd-devel] is such a 'failed' state?

2021-03-28 Thread Reindl Harald



Am 28.03.21 um 21:19 schrieb lejeczek:
I have a service (which for some reason, I suspect SELinux, does not 
start at boot) which reports as:


-> $ systemctl status -l lsyncd | cat
● lsyncd.service - Live Syncing (Mirror) Daemon
    Loaded: loaded (/usr/lib/systemd/system/lsyncd.service; enabled; 
vendor preset: disabled)

   Drop-In: /etc/systemd/system/lsyncd.service.d
    └─override.conf
    Active: inactive (dead) since Sun 2021-03-28 15:01:16 EDT; 8min ago
  Main PID: 922 (code=exited, status=0/SUCCESS)

Mar 28 15:01:16 c8kubernode2.private.pawel systemd[1]: Started Live 
Syncing (Mirror) Daemon.
Mar 28 15:01:16 c8kubernode2.private.pawel lsyncd[922]: 15:01:16 Normal: 
--- Startup, daemonizing ---
Mar 28 15:01:16 c8kubernode2.private.pawel lsyncd[922]: 15:01:16 Normal: 
--- Startup, daemonizing ---
Mar 28 15:01:16 c8kubernode2.private.pawel lsyncd[981]: Normal, --- TERM 
signal, fading ---
Mar 28 15:01:16 c8kubernode2.private.pawel systemd[1]: lsyncd.service: 
Succeeded.


and the service has:
[Service]
Restart=on-failure
RestartSec=30
TimeoutSec=30

I expected systemd to restart the service but that does not happen. 
Services restarts okey with manual intervention.
Is it because service, even though it's not running, is not really in 
'failed' state or root cause is something else?


post the complete unit file
you don't even show us the Type

do you have an [Install] section with a active traget to begin with?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Only start a tomcat server when you are sure that time-sync.target is online

2021-03-25 Thread Reindl Harald




Am 25.03.21 um 15:11 schrieb Jan Hugo Prins:

> Does systemd give me a different way to check if the time is in sync?
> Is there a way to create this dependency without implying a restart when
> ntpd restarts?
https://unix.stackexchange.com/questions/388586/systemd-requires-vs-wants 



just replace "Requires" with "Wants", it does exactly the same but your
Tomcat would also get started if "time-sync.target" is missing *but* it
would not be stopped just because ntpd is stopped

there are really very few cases when Requires is really what someone wants


We first tried it with wants, but wants does start the application 
server even if the time-sync.target does not work.


 From the man page:
    Units listed in this option will be started if the 
configuring unit is. *However, if the listed units fail to start or 
cannot be added to the**
**   transaction, this has no impact on the validity of the 
transaction as a whole*, and this unit will still be started. This is 
the recommended
    way to hook the start-up of one unit to the start-up of 
another unit.


We don't want tomcat to start when time-sync doesn't succeed, but when 
ntpd restarts it should not influence tomcat.


you need to chose one death

when you say "it requires X" the logical result of taking X down is that 
both are going down


how high is the chance that ntpd don't start and in the reality (didn't 
have that a single time) how large is the drift on a typical 365/24 on 
machine at reboot?


in fact look at "ntpq -p" after restart - it take ssome time until it 
really is operational no matter if it started successful


you are creating more troubles than you solve and should better make 
sure that ntpd.service is automatically restarted in case it fails and 
is properly ordered after network

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


Re: [systemd-devel] Only start a tomcat server when you are sure that time-sync.target is online

2021-03-25 Thread Reindl Harald




Am 25.03.21 um 14:41 schrieb Jan Hugo Prins:

Our current configuration looks roughly like this:

[Unit]
Description=Apache Tomcat Web Application Container
After=syslog.target time-sync.target
Requires=time-sync.target

[Service]
Type=simple
ExecStart=Startscripts
ExecStop=Stopscript
SuccessExitStatus=143
User=tomcatuser
Group=tomcatuser
Restart=on-failure

[Install]
WantedBy=multi-user.target

The problem line is the Requires line in there I think.


yes


Does systemd give me a different way to check if the time is in sync?
Is there a way to create this dependency without implying a restart when
ntpd restarts?

https://unix.stackexchange.com/questions/388586/systemd-requires-vs-wants

just replace "Requires" with "Wants", it does exactly the same but your 
Tomcat would also get started if "time-sync.target" is missing *but* it 
would not be stopped just because ntpd is stopped


there are really very few cases when Requires is really what someone wants
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


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

2021-03-11 Thread Reindl Harald




Am 11.03.21 um 12:17 schrieb Ulrich Windl:

Hi!

I have a unit that uses logger, and I want to run it after syslog is available. 
So I added syslog.socket as dependency, but it fails:
Mar 11 12:11:02 jeos1 systemd[1]: syslog.socket: Socket service syslog.service 
not loaded, refusing.
Mar 11 12:11:02 jeos1 systemd[1]: Failed to listen on Syslog Socket.

Doesn't journald also "provide" syslog.socket?

Manual says:
syslog.socket
The socket unit syslog implementations should listen on. All
userspace log messages will be made available on this socket. For
more information about syslog integration, please consult the
Syslog Interface[2] document


you need no dependencies for logging - journald is responsible for that 
and even available in the initrd


it's where early-boot stuff comes from
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Activate netdev only on demand (e.g. for wireguard connection)

2021-03-11 Thread Reindl Harald




Am 11.03.21 um 06:36 schrieb Amish:

Hello

So I have a wireguard setup which I use to connect to my server.

But I do not connect to it daily, just once a in a while.

I have setup wg0.netdev file and wg0.network file and all is working fine.

But how do I set it up such that interface wg0 does not connect 
automatically but comes up only when I run:


#networkctl up wg0

Effectively I want wireguard to connect/disconnect on demand


given that wireguard runs directly in the kernel and has no single 
userland process what problem would you like to solve and why?

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


Re: [systemd-devel] Antw: [EXT] D-bus connection Unknown error

2021-03-03 Thread Reindl Harald




Am 03.03.21 um 07:59 schrieb Ulrich Windl:

Shiju Email <994...@gmail.com> schrieb am 02.03.2021 um 22:27 in Nachricht

:

Hi, I am getting an error when any systemctl commands are issued.

Failed to get D-bus connection: Unknown error -1


I have no idea, but I think "unknown error" is bad programming style; it's
like "something went wrong; go and figure..."


it's the "you should never reach that" codepath and is at least a better 
programming style than crash when something you din't think of happens

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


Re: [systemd-devel] Q: Roles for a one-shot service

2021-02-24 Thread Reindl Harald




Am 25.02.21 um 08:12 schrieb Ulrich Windl:

Hi!

I wonder: I'm thinking of a monitoring-type of one-shot service that should be 
run periodically to update some external status display with runtime data.
In addition to that periodic activations, I'd like to run the service also 
during boot and shutdown, possibly supplying a special parameter to indicate 
that a boot or shutdown is happening.
I'm unsure how to model that with systemd. Should I define one service or three 
services?
Any proposals?


seperate services is clearly the systemd way and given how easy they are 
to write keep them simple and specific

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


Re: [systemd-devel] Unprivileged user can kill root-owned processes by changing PID file and stopping service

2021-02-19 Thread Reindl Harald




Am 19.02.21 um 21:05 schrieb Frank Thommen:



Lennart Poettering  hat am 19.02.2021 15:44 geschrieben:

  
On Fr, 19.02.21 15:12, Frank Thommen (systemd-de...@lists.drosera.ch) wrote:



Dear all,

I am experiencing the issue, that an unprivileged user can kill
root-owned processes by changing a service's PIDFile.


The file referenced by PIDFile= should not be under control of an
unpriv user.

v219 is more than 5 years old. Since then we have tightened controls:


I am aware of this, but unfortunately for the time being we are stuck with this 
version (CentOS 7.4)


i yet need to see a real world usecase which needs "PIDFile=" at all - 
systemd kills everything in the cgroup anyways at stop


i even start mariadb with --pid-file=/dev/null and without "mysqlsafe" 
for years to get rid of all that shit


not a single service is using "PIDFile=" for years here and frankly i 
even forked systemd units only to get rid of that nosense from the 1990s

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


Re: [systemd-devel] Looking for known memory leaks triggered by stress testing add/remove/up/down interfaces

2021-02-19 Thread Reindl Harald




Am 19.02.21 um 11:28 schrieb Robert P. J. Day:

   I *may* have found the problem ... as one can read here:

https://access.redhat.com/solutions/3840481

"CVE-2019-3815 systemd: memory leak in journald-server.c introduced by
fix for CVE-2018-16864"

   So as I interpret that, a memory leak introduced by that earlier CVE
had to be corrected by that later CVE. I checked the state of
systemd_230 as shipped by WRL9, and it comes with an extensive set of
patches, which includes the earlier CVE, but *not* the later one.

   Hmmm ...


that one should have been fixed long ago
https://bugzilla.redhat.com/show_bug.cgi?id=1665931


but your original mail didn't talk about journald at all


 Weitergeleitete Nachricht 
Betreff: [systemd-devel] Looking for known memory leaks triggered by 
stress testing add/remove/up/down interfaces

Datum: Thu, 18 Feb 2021 11:48:58 -0500 (EST)
Von: Robert P. J. Day 
An: Systemd mailing list 


  A colleague has reported the following apparent issue in a fairly
old (v230) version of systemd -- this is in a Yocto Project Wind River
Linux 9 build, hence the age of the package.

  As reported to me (and I'm gathering more info), the system was
being put through some "longevity testing" by repeatedly adding,
removing, activating and de-activating network interfaces. According
to the report, the result was heap space slowly but inexorably being
consumed.

  While waiting for more info, I'm going to examine the commit log for
systemd from v230 moving forward to collect any commits that address
memory leaks, then peruse them more carefully to see if they might
resolve the problem.

  I realize it's asking a bit for folks here to remember that far
back, but does this issue sound at all familiar? Any pointers that
might save me some time? Thanks.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Antw: [EXT] Re: Looking for known memory leaks triggered by stress testing add/remove/up/down interfaces

2021-02-19 Thread Reindl Harald




Am 19.02.21 um 08:44 schrieb Ulrich Windl:

Lennart Poettering  schrieb am 18.02.2021 um 19:30

in
Nachricht :
...

entry instead of asking for new memory again. This allocation cache is
a bit quicker then going to malloc() all the time, but means if you
just watch the heap you'll assume there's a leak even though there
isn't really, the memory is not lost after all, and will be reused
eventually if we need it.


That's an interesting point of view: If you save memory in case you might need
it at some unspecified later time (which includes "never") it's "practically"
(while not theoretically) a memory leak


following that logic every memory pool and mysql buffer would be a memleak

a memleak is *unintended* and never freed memory allocation, practically 
as well as theoretically


you can argue about the size of such cases but it don't make them a 
memleak to begin with

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


Re: [systemd-devel] sys-module-fuse.device: Failed to enqueue SYSTEMD_WANTS= job, ignoring: Unit modprobe@fuse.service is masked

2021-02-13 Thread Reindl Harald



Am 08.02.21 um 23:42 schrieb Mike Gilbert:

On Mon, Feb 8, 2021 at 2:31 PM Reindl Harald  wrote:

I think removing this symlink would prevent /sys/fs/fuse/connections
from being mounted and the fuse module from being loaded
unconditionally on boot


no

https://bugzilla.redhat.com/show_bug.cgi?id=1909805#c6


It almost works for me on Gentoo Linux.
To test, I first had to reconfigure my kernel to build FUSE as a
module (I normally have it built-in).
I then removed the sys-fs-fuse-connections.mount symlink from
sysinit.target.wants.
After rebooting with the new kernel, the FUSE module is not loaded and
/sys/fs/fuse/connections is not mounted.

Unfortunately, mounting FUSE-based file systems does not work until I
manually run "modprobe fuse".
It seems that my kernel does not auto-load the module, despite the
static /dev/fuse node. The kernel is probably missing a call to
__request_module().

Given that the kernel doesn't auto-load the module on demand, leaving
the sysinit.target.wants symlink in place seems like the safe thing to
do.


but for sure not on a stripped down machine running a iptables-nft 
ruleset, a socket-activated sshd and nohting else


if it's me for server setups the "fuse" kernel-module could be in 
"kernel-modules" which is not installed and needed for virtualized guests


the point is that all this setups where happy without fuse loaded from 
2008 to 2021 and you can't even avoid it with F33 at all, no matter what 
you delete or mask


a active masked unit - seriously? :-)

[root@rawhide ~]# systemctl status sys-module-fuse.device 
sys-fs-fuse-connections.mount

● sys-module-fuse.device - /sys/module/fuse
 Loaded: masked (Reason: Unit sys-module-fuse.device is masked.)
 Active: active (plugged) since Mon 2021-02-08 19:33:18 CET; 1min 
42s ago

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


Re: [systemd-devel] sys-module-fuse.device: Failed to enqueue SYSTEMD_WANTS= job, ignoring: Unit modprobe@fuse.service is masked

2021-02-13 Thread Reindl Harald



Am 09.02.21 um 17:13 schrieb Mike Gilbert:

On Tue, Feb 9, 2021 at 6:17 AM Reindl Harald  wrote:




Am 08.02.21 um 23:42 schrieb Mike Gilbert:

On Mon, Feb 8, 2021 at 2:31 PM Reindl Harald  wrote:

I think removing this symlink would prevent /sys/fs/fuse/connections
from being mounted and the fuse module from being loaded
unconditionally on boot


no

https://bugzilla.redhat.com/show_bug.cgi?id=1909805#c6


It almost works for me on Gentoo Linux.
To test, I first had to reconfigure my kernel to build FUSE as a
module (I normally have it built-in).
I then removed the sys-fs-fuse-connections.mount symlink from
sysinit.target.wants.
After rebooting with the new kernel, the FUSE module is not loaded and
/sys/fs/fuse/connections is not mounted.

Unfortunately, mounting FUSE-based file systems does not work until I
manually run "modprobe fuse".
It seems that my kernel does not auto-load the module, despite the
static /dev/fuse node. The kernel is probably missing a call to
__request_module().

Given that the kernel doesn't auto-load the module on demand, leaving
the sysinit.target.wants symlink in place seems like the safe thing to
do.


but for sure not on a stripped down machine running a iptables-nft
ruleset, a socket-activated sshd and nohting else

if it's me for server setups the "fuse" kernel-module could be in
"kernel-modules" which is not installed and needed for virtualized guests

the point is that all this setups where happy without fuse loaded from
2008 to 2021 and you can't even avoid it with F33 at all, no matter what
you delete or mask

a active masked unit - seriously? :-)

[root@rawhide ~]# systemctl status sys-module-fuse.device
sys-fs-fuse-connections.mount
● sys-module-fuse.device - /sys/module/fuse
   Loaded: masked (Reason: Unit sys-module-fuse.device is masked.)
   Active: active (plugged) since Mon 2021-02-08 19:33:18 CET; 1min
42s ago
   Device: /sys/module/fuse


I think something else on your system is loading the fuse kernel
module, which activates sys-module-fuse.device, and tries to start
sys-fs-fuse-connections.mount. It appears systemd doesn't really
support masking device units, which are generated by udev events.

You should probably try to track down exactly what else is loading the
fuse module, and disable that.


this is a bare setup with *nothing* enabled at all

[root@rawhide ~]# pstree
systemd─┬─agetty
├─dbus-broker-lau───dbus-broker
├─haveged
├─rsyslogd───2*[{rsyslogd}]
├─sshd───sshd───bash───pstree
├─systemd───(sd-pam)
├─systemd-journal
├─systemd-logind
├─systemd-udevd
└─vmtoolsd───2*[{vmtoolsd}]

[root@rawhide ~]# systemd-analyze
Startup finished in 942ms (kernel) + 1.519s (initrd) + 1.725s 
(userspace) = 4.187s

multi-user.target reached after 1.692s in userspace
[root@rawhide ~]# systemd-analyze blame
376ms systemd-udev-trigger.service
309ms initrd-switch-root.service
234ms systemd-logind.service
181ms initrd-parse-etc.service
178ms network-up.service
151ms systemd-journald.service
120ms dracut-cmdline.service
118ms systemd-udevd.service
117ms systemd-vconsole-setup.service
107ms user@0.service
 89ms rsyslog.service
 66ms dbus-broker.service
 57ms sys-kernel-tracing.mount
 57ms dev-mqueue.mount
 56ms sys-kernel-debug.mount
 55ms dev-hugepages.mount
 55ms tmp.mount
 54ms kmod-static-nodes.service
 46ms modprobe@drm.service
 43ms systemd-sysctl.service
 40ms var-lib-dnf.mount
 39ms var-cache-yum.mount
 39ms systemd-modules-load.service
 36ms initrd-cleanup.service
 36ms systemd-remount-fs.service
 36ms systemd-tmpfiles-setup.service
 34ms systemd-random-seed.service
 33ms sys-kernel-config.mount
 32ms systemd-tmpfiles-setup-dev.service
 30ms systemd-fsck-root.service
 30ms systemd-user-sessions.service
 29ms var-log.mount
 24ms systemd-update-utmp.service
 23ms var-tmp.mount
 23ms systemd-update-utmp-runlevel.service
 22ms systemd-journal-flush.service
 14ms user-runtime-dir@0.service
 11ms initrd-udevadm-cleanup-db.service
  9ms dracut-shutdown.service
  8ms sysroot.mount
  4ms modprobe@configfs.service

[root@rawhide ~]# systemctl -list-units
Failed to parse signal string t-units.
[root@rawhide ~]# systemctl list-units
  UNIT 
LOAD   ACTIVE SUB   DESCRIPTION 

  boot.automount 
loaded active waiting   boot.automount 

  efi.automount 
loaded active waiting   efi.automount 

  sys-devices-pci:00-:00:15.0-:03:00.0-net-lan.device 
loaded active plugged   VMXNET3 Ethernet 
Controller


sys-devices-pci:00-:00:17.0-:13:00.0-host2-target2:0:0-2:0:0:0-block-sda-sda1.device 
loaded active plugged   VMware_Virtual_S EFI\x20system\x20partition 



sys-devices-pci:00-:00:17.0-:13:00.0-host2-target2:0:0-2:0:0:0-block-sda-sda2.device 
loaded active plugged   VMware_Virtual_S BIOS\x20boot\x20partition 



sys-device

Re: [systemd-devel] sys-module-fuse.device: Failed to enqueue SYSTEMD_WANTS= job, ignoring: Unit modprobe@fuse.service is masked

2021-02-13 Thread Reindl Harald



Am 09.02.21 um 23:18 schrieb Mike Gilbert:

On Tue, Feb 9, 2021 at 11:47 AM Reindl Harald  wrote:




Am 09.02.21 um 17:13 schrieb Mike Gilbert:

On Tue, Feb 9, 2021 at 6:17 AM Reindl Harald  wrote:




Am 08.02.21 um 23:42 schrieb Mike Gilbert:

On Mon, Feb 8, 2021 at 2:31 PM Reindl Harald  wrote:

I think removing this symlink would prevent /sys/fs/fuse/connections
from being mounted and the fuse module from being loaded
unconditionally on boot


no

https://bugzilla.redhat.com/show_bug.cgi?id=1909805#c6


It almost works for me on Gentoo Linux.
To test, I first had to reconfigure my kernel to build FUSE as a
module (I normally have it built-in).
I then removed the sys-fs-fuse-connections.mount symlink from
sysinit.target.wants.
After rebooting with the new kernel, the FUSE module is not loaded and
/sys/fs/fuse/connections is not mounted.

Unfortunately, mounting FUSE-based file systems does not work until I
manually run "modprobe fuse".
It seems that my kernel does not auto-load the module, despite the
static /dev/fuse node. The kernel is probably missing a call to
__request_module().

Given that the kernel doesn't auto-load the module on demand, leaving
the sysinit.target.wants symlink in place seems like the safe thing to
do.


but for sure not on a stripped down machine running a iptables-nft
ruleset, a socket-activated sshd and nohting else

if it's me for server setups the "fuse" kernel-module could be in
"kernel-modules" which is not installed and needed for virtualized guests

the point is that all this setups where happy without fuse loaded from
2008 to 2021 and you can't even avoid it with F33 at all, no matter what
you delete or mask

a active masked unit - seriously? :-)

[root@rawhide ~]# systemctl status sys-module-fuse.device
sys-fs-fuse-connections.mount
● sys-module-fuse.device - /sys/module/fuse
Loaded: masked (Reason: Unit sys-module-fuse.device is masked.)
Active: active (plugged) since Mon 2021-02-08 19:33:18 CET; 1min
42s ago
Device: /sys/module/fuse


I think something else on your system is loading the fuse kernel
module, which activates sys-module-fuse.device, and tries to start
sys-fs-fuse-connections.mount. It appears systemd doesn't really
support masking device units, which are generated by udev events.

You should probably try to track down exactly what else is loading the
fuse module, and disable that.


this is a bare setup with *nothing* enabled at all


Off the top of my head, maybe fuse is getting loaded by an entry in
modules-load.d.


no

[root@rawhide ~]# ls /etc/modules-load.d/
total 0


Also, vmware tools might utilize FUSE in some way.


no

[root@rawhide ~]# system-errors.sh
Feb 10 00:59:22 rawhide systemd[1]: sys-module-fuse.device: Failed to 
enqueue SYSTEMD_WANTS= job, ignoring: Unit sys-fs-fuse-connections.mount 
is masked.

[root@rawhide ~]# systemctl status vmtoolsd.service
● vmtoolsd.service - VMware Tools
 Loaded: loaded (/etc/systemd/system/vmtoolsd.service; disabled; 
vendor preset: enabled)

 Active: inactive (dead)

even that file from the vmtools package was deleted long before my 
initial post of this thread


[root@rawhide ~]# cat /usr/lib/systemd/system/run-vmblock\x2dfuse.mount
cat: /usr/lib/systemd/system/run-vmblockx2dfuse.mount: No such file or 
directory



If you're unable to figure out what is loading it, you might replace
/sbin/modprobe with a wrapper script to log all processes that call
it
there is nothing left but systemd which also don't go the normal way 
otherwise this below would prevent loading the kernel module


modprobe won't load it in that case

[root@rawhide ~]# cat /etc/modprobe.d/blacklist-lounge-vm.conf | grep fuse
blacklist fuse
install fuse /usr/bin/true

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


Re: [systemd-devel] Antw: [EXT] Re: sys-module-fuse.device: Failed to enqueue SYSTEMD_WANTS= job, ignoring: Unit modprobe@fuse.service is masked

2021-02-09 Thread Reindl Harald



Am 09.02.21 um 08:54 schrieb Ulrich Windl:

Reindl Harald  schrieb am 08.02.2021 um 19:01 in

Nachricht :



Am 08.02.21 um 18:27 schrieb Lennart Poettering:

On So, 07.02.21 22:43, Reindl Harald (h.rei...@thelounge.net) wrote:


https://bugzilla.redhat.com/show_bug.cgi?id=1909805


In response to your actual issue, ignoring all the nasty wording:

Masking is a last resort thing, you really want to use that only after
having investigated everything. You use it here anyway to mask out a
really low‑level system thing, hence you might get warnings about
this.

You can of course mask sys‑fs‑fuse‑connections.mount too

who needs anything related to fuse at every boot?
fuse is nothing in common used
fuse is not used unconditional

directly after boot on a server‑vm with no fuse business

[root@testserver:~]$ lsmod | grep fuse
fuse  163840  1


First it seems you fuse module is used by another module, and then in SLES15
SP2 with libvirt and two running Xen PVMs, I see no fuse being used or even
loaded. So maybe find out who requests fuse...



nobody and nothing requests it except systemd is triggering the loading

don't compare your SLES with a completly stripped down Fedora 33 only 
running sshd - with F32 for now masking "sys-fs-fuse-connections.mount" 
is enough, on F33 not


[harry@srv-rhsoft:~]$ rawhide
[root@rawhide ~]# lsmod
Module  Size  Used by
nft_counter16384  4
ipt_REJECT 16384  1
nf_reject_ipv4 16384  1 ipt_REJECT
xt_multiport   20480  1
xt_conntrack   16384  1
nf_conntrack  163840  1 xt_conntrack
nf_defrag_ipv6 24576  1 nf_conntrack
nf_defrag_ipv4 16384  1 nf_conntrack
nft_compat 20480  3
nf_tables 241664  9 nft_compat,nft_counter
nfnetlink  16384  2 nft_compat,nf_tables
crct10dif_pclmul   16384  1
crc32_pclmul   16384  0
ghash_clmulni_intel16384  0
vmw_balloon28672  0
vmw_vmci   90112  1 vmw_balloon
vmxnet369632  0
ip_tables  28672  0
crc32c_intel   24576  1
vmw_pvscsi 32768  1
fuse  163840  0

[root@rawhide ~]# system-errors.sh
Feb  9 12:03:32 rawhide systemd[1]: sys-module-fuse.device: Failed to 
enqueue SYSTEMD_WANTS= job, ignoring: Unit sys-fs-fuse-connections.mount 
is masked.

[root@rawhide ~]# rmmod fuse
[root@rawhide ~]#

even if you *delete* the 
"sysinit.target.wants/sys-fs-fuse-connections.mount"

no, basic target don't want fuse

[harry@srv-rhsoft:~]$ rawhide
[root@rawhide ~]# system-errors.sh
Feb  8 19:32:20 rawhide systemd[1]: sys-module-fuse.device: Failed to 
enqueue SYSTEMD_WANTS= job, ignoring: Unit sys-fs-fuse-connections.mount 
is masked.

[root@rawhide ~]# rpm -q --filesbypkg systemd | grep fuse
systemd 
/usr/lib/systemd/system/sys-fs-fuse-connections.mount
systemd 
/usr/lib/systemd/system/sysinit.target.wants/sys-fs-fuse-connections.mount
[root@rawhide ~]# rm 
/usr/lib/systemd/system/sysinit.target.wants/sys-fs-fuse-connections.mount

[root@rawhide ~]# rm /usr/lib/systemd/system/sys-fs-fuse-connections.mount
[root@rawhide ~]# reboot

[root@rawhide ~]# system-errors.sh
Feb  8 19:33:19 rawhide systemd[1]: sys-module-fuse.device: Failed to 
enqueue SYSTEMD_WANTS= job, ignoring: Unit sys-fs-fuse-connections.mount 
is masked.


[root@rawhide ~]# systemctl status sys-module-fuse.device 
sys-fs-fuse-connections.mount

● sys-module-fuse.device - /sys/module/fuse
 Loaded: masked (Reason: Unit sys-module-fuse.device is masked.)
 Active: active (plugged) since Mon 2021-02-08 19:33:18 CET; 1min 
42s ago

 Device: /sys/module/fuse

Feb 08 19:33:19 rawhide.vmware.local systemd[1]: sys-module-fuse.device: 
Failed to enqueue SYSTEMD_WANTS= job, ignoring: Unit 
sys-fs-fuse-connections.mount is masked.


● sys-fs-fuse-connections.mount
 Loaded: masked (Reason: Unit sys-fs-fuse-connections.mount is masked.)
 Active: inactive (dead)
[root@rawhide ~]#

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


Re: [systemd-devel] sys-module-fuse.device: Failed to enqueue SYSTEMD_WANTS= job, ignoring: Unit modprobe@fuse.service is masked

2021-02-09 Thread Reindl Harald




Am 08.02.21 um 20:23 schrieb Mike Gilbert:

On Mon, Feb 8, 2021 at 1:01 PM Reindl Harald  wrote:




Am 08.02.21 um 18:27 schrieb Lennart Poettering:

On So, 07.02.21 22:43, Reindl Harald (h.rei...@thelounge.net) wrote:


https://bugzilla.redhat.com/show_bug.cgi?id=1909805


In response to your actual issue, ignoring all the nasty wording:

Masking is a last resort thing, you really want to use that only after
having investigated everything. You use it here anyway to mask out a
really low-level system thing, hence you might get warnings about
this.

You can of course mask sys-fs-fuse-connections.mount too

who needs anything related to fuse at every boot?
fuse is nothing in common used
fuse is not used unconditional

directly after boot on a server-vm with no fuse business

[root@testserver:~]$ lsmod | grep fuse
fuse  163840  1

my only usecase on 50 machines is every few weeks fuse.sshfs abd what
makes people nasty is that for months nobody responds to systemd related
issues in the Fedora bugracker

if something is usiong fuse it happily loads the kernel module on-demand
for years


Looking into this a bit closer, it looks like systemd installs a symlink:

/usr/lib/systemd/system/sysinit.target.wants/sys-fs-fuse-connections.mount
-> ../sys-fs-fuse-connections.mount

I think removing this symlink would prevent /sys/fs/fuse/connections
from being mounted and the fuse module from being loaded
unconditionally on boot


no

https://bugzilla.redhat.com/show_bug.cgi?id=1909805#c6
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] sys-module-fuse.device: Failed to enqueue SYSTEMD_WANTS= job, ignoring: Unit modprobe@fuse.service is masked

2021-02-08 Thread Reindl Harald



Am 08.02.21 um 18:27 schrieb Lennart Poettering:

Masking is a last resort thing, you really want to use that only after
having investigated everything. You use it here anyway to mask out a
really low-level system thing, hence you might get warnings about
this.

You can of course mask sys-fs-fuse-connections.mount too


no, you can't at least on F33

"systemctl mask sys-fs-fuse-connections.mount" only works on F32 at the 
moment, on F33 "sys-module-fuse.device" is masked but at the same moment 
"active (plugged)" and cries for "sys-fs-fuse-connections.mount"


fuse kernel module is loaded on a bare install after reboot - please get 
your facts straight, i already tried to mask them last year *before* 
writing the ignored bug report at the fedora bugzilla


[root@rawhide ~]# system-errors.sh
Feb  8 19:17:01 rawhide systemd[1]: sys-module-fuse.device: Failed to 
enqueue SYSTEMD_WANTS= job, ignoring: Unit sys-fs-fuse-connections.mount 
is masked.


[root@rawhide ~]# systemctl status sys-module-fuse.device 
sys-fs-fuse-connections.mount

● sys-module-fuse.device - /sys/module/fuse
 Loaded: masked (Reason: Unit sys-module-fuse.device is masked.)
 Active: active (plugged) since Mon 2021-02-08 19:17:00 CET; 5min ago
 Device: /sys/module/fuse

Feb 08 19:17:01 rawhide.vmware.local systemd[1]: sys-module-fuse.device: 
Failed to enqueue SYSTEMD_WANTS= job, ignoring: Unit 
sys-fs-fuse-connections.mount is masked.


● sys-fs-fuse-connections.mount
 Loaded: masked (Reason: Unit sys-fs-fuse-connections.mount is masked.)
 Active: inactive (dead)
[root@rawhide ~]#
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] sys-module-fuse.device: Failed to enqueue SYSTEMD_WANTS= job, ignoring: Unit modprobe@fuse.service is masked

2021-02-08 Thread Reindl Harald




Am 08.02.21 um 18:27 schrieb Lennart Poettering:

On So, 07.02.21 22:43, Reindl Harald (h.rei...@thelounge.net) wrote:


https://bugzilla.redhat.com/show_bug.cgi?id=1909805


In response to your actual issue, ignoring all the nasty wording:

Masking is a last resort thing, you really want to use that only after
having investigated everything. You use it here anyway to mask out a
really low-level system thing, hence you might get warnings about
this.

You can of course mask sys-fs-fuse-connections.mount too

who needs anything related to fuse at every boot?
fuse is nothing in common used
fuse is not used unconditional

directly after boot on a server-vm with no fuse business

[root@testserver:~]$ lsmod | grep fuse
fuse  163840  1

my only usecase on 50 machines is every few weeks fuse.sshfs abd what 
makes people nasty is that for months nobody responds to systemd related 
issues in the Fedora bugracker


if something is usiong fuse it happily loads the kernel module on-demand 
for years





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


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

2021-02-08 Thread Reindl Harald




Am 08.02.21 um 14:52 schrieb Uoti Urpala:

On Mon, 2021-02-08 at 11:27 +0100, Reindl Harald wrote:

this is *not* what systemd-sockets are for
they are for service is started at the first connect


This is wrong. Socket units are useful completely independently of
whether the unit is started on demand, and it's a good idea to use them
even for services that are always started on boot. They allow
configuring listening ports in a consistent manner, and make it
possible to avoid direct dependencies between services. The latter
pretty much avoids all further issues with ordering: once you've
started all the sockets, you can freely start all the services in
parallel or in whatever order - a depended-on service process starting
later is never a problem, since requests will just get queued in the
socket and will work fine once the service is fully up. In principle,
you could even have two services which both require the other, as long
as the exact requests they make will not result in a deadlock. In
almost any setup at least the improved parallelism improves performance
at boot or when otherwise starting services.


that's all nice but when you want what the OP wnats it makes no sense 
and as long as my machines are boot in 3-12 seconds added complexity 
needs to find a problem to solve


the point is: when your configuration can't handle sockets or you can't 
handle them just don't use them for the sake of using them with no 
measureable benefit


it can't boot fast enough to compensate all the "fuck it i said stop the 
service" of the past 10 years and as long systemd is not smart enough 
that "systemctl stop x" stops both, the service and the socket unit that 
makes no fun at all

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


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

2021-02-08 Thread Reindl Harald



Am 08.02.21 um 10:10 schrieb Ulrich Windl:

Andrei Borzenkov  schrieb am 06.02.2021 um 09:14 in

Nachricht <09aa6a69-ee37-ffea-c4fd-e4c5d3327...@gmail.com>:

04.02.2021 10:47, Ulrich Windl пишет:

...

I had provided the full units yesterday. Basically I don't know what to do:



I

just want to start the service and its sockets at a specific point in time



and

also want to stop those at another time.



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


All I want is that the sockets that need to listen actually do listen when the
service start.
It seems systemd messes with that in a bad way


this is *not* what systemd-sockets are for
they are for service is started at the first connect

what you want is the classical "i start a service and it listens, i stop 
a service and it don't listen any longer"


so just do that and leave socket-activation alone, no need for any 
.socket unit at all


in other words:

* you don't want socket activation
* just do not use socket activation


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


[systemd-devel] sys-module-fuse.device: Failed to enqueue SYSTEMD_WANTS= job, ignoring: Unit modprobe@fuse.service is masked

2021-02-07 Thread Reindl Harald

https://bugzilla.redhat.com/show_bug.cgi?id=1909805

what is this new nonsense given that only one out of 50 installs here 
have a business for fuse at all and there is no reason to load/touch any 
fuse related stuff at boot

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


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

2021-02-04 Thread Reindl Harald




Am 04.02.21 um 12:46 schrieb Benjamin Berg:

On Wed, 2021-02-03 at 16:43 +0100, Reindl Harald wrote:

seriously - explain what you expect to happen in case of

Requires=a.service
Before=a.service

except some warning that it's nonsense


So, one way I used it is as ExecStartPost= equivalent for a .target
unit. i.e. pull in a Type=oneshot service once a target has become
active in order to execute a simple command



"Requires=a.service" combined with "Before=a.service" is contradictory - 
don't you get that?

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


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

2021-02-03 Thread Reindl Harald



Am 03.02.21 um 10:43 schrieb Benjamin Berg:

On Wed, 2021-02-03 at 08:00 +0100, Reindl Harald wrote:



Am 02.02.21 um 22:25 schrieb Benjamin Berg:

On Tue, 2021-02-02 at 22:50 +0300, Andrei Borzenkov wrote:

02.02.2021 17:59, Lennart Poettering пишет:


Note that Requires= in almost all cases should be combined with
an
order dep of After= onto the same unit.


Years ago I asked for example when Requires makes sense without
After.
Care to show it? I assume you must have use case if you say "in
almost all".


In the GNOME systemd units there are a few places where a Requires=
is
combined with Before=


sounds like complete nonsense

you can not require something at your own to be there but on the other
hand start before it - at least by common sense


The units are indeed non-trivial. I have put in a lot of effort to find
a solution that both works and is robust in various failure modes. It
may well be that there is a better approach with similar properties.
But, session login and logout(!) is not quite as trivial as one could
hope for unfortunately (backward compatibility and workarounds add some
complexities).

So, I would love to be educated on how to simplify all this while still
catching the various corner cases. But in order to convince me, you'll
need to make a more concrete suggestion and explain its properties


seriously - explain what you expect to happen in case of

Requires=a.service
Before=a.service

except some warning that it's nonsense

you need a.service but want to be started before a.service sounds like 
wash me but don't make me wet

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


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

2021-02-02 Thread Reindl Harald



Am 02.02.21 um 22:25 schrieb Benjamin Berg:

On Tue, 2021-02-02 at 22:50 +0300, Andrei Borzenkov wrote:

02.02.2021 17:59, Lennart Poettering пишет:


Note that Requires= in almost all cases should be combined with an
order dep of After= onto the same unit.


Years ago I asked for example when Requires makes sense without
After.
Care to show it? I assume you must have use case if you say "in
almost all".


In the GNOME systemd units there are a few places where a Requires= is
combined with Before=


sounds like complete nonsense

you can not require something at your own to be there but on the other 
hand start before it - at least by common sense

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


Re: [systemd-devel] service runs - but it's not really there

2021-01-29 Thread Reindl Harald




Am 29.01.21 um 16:27 schrieb lejeczek:
I think I found it, in my opinion a very cheeky bastard - syncthing - 
who does this:


[Install]
WantedBy=default.target

which results in:

-> $ llr /etc/systemd/user/default.target.wants/
total 0
lrwxrwxrwx. 1 root root 39 Jan 26 10:39 syncthing.service -> 
/usr/lib/systemd/user/syncthing.service


So those of you on RHEL and derivatives (I assume that same rpm goes 
to all those) - suffices to install "syncthing" an you have your 
"roor" does as above and if you are not aware then the "root" does 
that with you not even knowing.


As a matter of sharing opinions - is that a good & healthy practice 
to make & distribute packages like that?


what is your problem?

it's an ordinary user session and not some mystery of "root does as 
above"


RTFM 
https://www.freedesktop.org/software/systemd/man/u...@.service.html 
instead talking about "very cheeky bastard - syncthin"
I doubt I can explain or express it any better, If you do not get it 
it's fine
there is nothing to explain - you found something you don't understand 
and see a not existing issue


either read manuals or ignore it - but move on
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] service runs - but it's not really there

2021-01-29 Thread Reindl Harald



Am 29.01.21 um 13:55 schrieb lejeczek:

● user@0.service - User Manager for UID 0
    Loaded: loaded (/usr/lib/systemd/system/user@.service; static; 
vendor

preset: disabled)
    Active: active (running) since Thu 2021-01-28 17:13:01 GMT; 2h 
34min ago

  Main PID: 854314 (systemd)
    Status: "Startup finished in 44ms."
 Tasks: 35
    Memory: 69.3M
    CGroup: /user.slice/user-0.slice/user@0.service
    ├─init.scope
    │ ├─854314 /usr/lib/systemd/systemd --user
    │ └─854319 (sd-pam)
    └─syncthing.service

exists and gets auto started by "systemd" without any asking really.
This is really very bad, no?
What am I missing here?

systemd at the very least will spawn your per-user dbus daemon, which
is needs to be available for many programs to function. Even others
require systemd themselves.

Lennart

--
Lennart Poettering, Berlin
I think I found it, in my opinion a very cheeky bastard - syncthing - 
who does this:


[Install]
WantedBy=default.target

which results in:

-> $ llr /etc/systemd/user/default.target.wants/
total 0
lrwxrwxrwx. 1 root root 39 Jan 26 10:39 syncthing.service -> 
/usr/lib/systemd/user/syncthing.service


So those of you on RHEL and derivatives (I assume that same rpm goes to 
all those) - suffices to install "syncthing" an you have your "roor" 
does as above and if you are not aware then the "root" does that with 
you not even knowing.


As a matter of sharing opinions - is that a good & healthy practice to 
make & distribute packages like that?


what is your problem?

it's an ordinary user session and not some mystery of "root does as above"

RTFM https://www.freedesktop.org/software/systemd/man/u...@.service.html 
instead talking about "very cheeky bastard - syncthin"

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


Re: [systemd-devel] What exactly is multi-seat? -- questions about logind

2021-01-26 Thread Reindl Harald




Am 26.01.21 um 10:43 schrieb Kian Kasad:

Hi all,

After reading the documentation on logind and multi-seat (specifically
sd-login(3) and "Multi-Seat on Linux"), I still have some questions.

First of all, what exactly is multi-seat? 


Google "systemd multiseat" links to 
https://www.freedesktop.org/wiki/Software/systemd/multiseat/


it's really about seats, the stuff where you place your arse in front of 
your IO devices :-)



Does it just mean allowing
multiple sessions to be running at once, like for multiple users to be
logged into the same desktop, even though only one will be in use at a
time?

Second, why is logind needed for this? Is it not possible to do without
logind? I've run Xorg perfectly fine on systems without logind/systemd,
so is logind only needed for multiple sessions at once? Is it just to
handle the graphical device(s)?

Third, is multi-seat possible at all without logind?

Most of these questions arose because my main OS, Artix Linux, requires
logind (in the form of elogind) for Xorg, but I know that Xorg runs just
fine on Alpine Linux, which does not use logind at all


you can start X11 with "startx" line in the 1990s but who is doing it 
that way these days?

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


Re: [systemd-devel] Why systemd-nspawn is slower than docker, podman and qemu?! how to Improve nspawn performance?

2021-01-25 Thread Reindl Harald
there is a difference between theoretical academic benchmarks and real 
world load - if your workload isn't affected it's pointless


Am 25.01.21 um 14:00 schrieb Badr Elmers:


  Tomasz Torcz

In fact I m just comparing containers, I have no need yet for context 
switch, but I hope to understand why nspawn is slower and if there is 
something I can do to improve it, for example disabling spectre/meltdown 
mitigations improved nspawn a lot, so I was wondering if there is 
something else I can do to make nspawn as quick as podman/docker/qemu.



  Mantas Mikulėnas

I tested with  Export SYSTEMD_SECCOMP=0
no improvement, I still get the same result
thank you,
badr

On Mon, Jan 25, 2021 at 1:40 PM Badr Elmers > wrote:


I tested with Export SYSTEMD_SECCOMP=0
no improvement, I still get the same result
thank you,
badr

On Mon, Jan 25, 2021 at 1:14 PM Mantas Mikulėnas mailto:graw...@gmail.com>> wrote:

On Mon, Jan 25, 2021, 12:56 Badr Elmers mailto:badrelm...@gmail.com>> wrote:

Hi,
Why |nspawn| is slow compared to |docker||podman| and even
|qemu|?!
CPU tasks take twice of the time it takes in docker, podman
or qemu

here I filled a request to improve nspawn performance which
contain the steps and the full test result:
https://github.com/systemd/systemd/issues/18370


Do you know why systemd-nspawn is slower? how can I improve it?

thank you



Have you tried completely *disabling* the syscall filtering and
all other seccomp-based features? Export SYSTEMD_SECCOMP=0
before running nspawn and check if it makes any difference...


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


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

2021-01-13 Thread Reindl Harald



Am 07.01.21 um 09:15 schrieb Ulrich Windl:

Chris Murphy  schrieb am 06.01.2021 um 03:02 in

Nachricht
:

On Mon, Jan 4, 2021 at 12:43 PM Phillip Susi  wrote:
This is too long for a desktop or laptop use case. It should be around
15‑20 seconds. It's completely reasonable for users to reach for the
power button and force it off by 30 seconds.


Have you ever tried shutting down multiple virtual machines having disks on a
slow medium?


where is the problem?

my machines shutdown within a few seconds as lonmg there is no 
systemd-unit hanging around for minutes without a good reason


everytime in the past 10 years when shutown took more than 5 seconds it 
was some systemd-unit doing meditation


happens regulary when i reboot our HP microserver on CentOS7 with RAID10 
and LUKS on top of it - manually unlocked and mounted with a login 
script to enter the password


and no that never finishes, it always runs in a timeout, no matter how 
long the timeout is while my shutdown alias is closing LUKS and 
unmounting the filesystem *before* issue "reboot" or "poweroff"


[root@nfs:~]$ which reboot
alias reboot='/usr/bin/bash /usr/local/bin/storage-services.sh stop; 
/usr/bin/systemctl reboot'



Fedora Workstation Working Group is tracking an issue expressly to get
to around 20 seconds (or better).
https://pagure.io/fedora‑workstation/issue/163

It is a given there will be some kind of state or data loss by just
forcing a shutdown. I think what we need is the console, revealed by
ESC, needs to contain sufficient information on what and why the
reboot/shutdown is being held back. So that we can figure out why
those processes aren't terminating fast enough and get them fixed.


There may be bugs, and there may be processes that simply take time.


yes, and in case the stuff with the bugs is delaying important services 
which takes longer at it's own to even begin to stop you havbe a problem


for a unit which takes time for good reasons you can configure that in 
the unit itself, no reason that everything waits for minutes



A journaled file system should just do log replay at the next mount
and the file system itself will be fine. Fine means consistent. But


That's nonsense: I'd prefer to wait and NOT lose data.


if the battery goes empty you will lose data for sure

often the calculation how long the UPS can hold power isn't true when 
batteries get older and at the point a emergency shutdown is needed you 
have less time than expected

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


Re: [systemd-devel] Is LTO worth it?

2021-01-13 Thread Reindl Harald




Am 11.01.21 um 18:10 schrieb Michael Biebl:

Am Mo., 11. Jan. 2021 um 18:07 Uhr schrieb Reindl Harald
:

it don't make sense using different flags in CI and production builds,
especially LTO which often points out otherwise unvisible bugs


Such as? I don't remember any bug report which was uncovered by LTO
being enabled


buggy code not always leads to visble bugs with reports, the warnings 
typically increase with LTO


and https://www.avrfreaks.net/forum/compiler-bug-lto-only shows why it's 
nonsense to run CI with different flags than final builds


however the whole topic and "we've been using LTO in the Debian build 
for as long as I can remember, but I begin to question whether that is a 
good idea" in 2021 is very strange given that more or less the whole 
world goe sinto LTO for everything direction


https://www.google.com/search?q=compiler+warnings+with+LTO

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


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

2021-01-13 Thread Reindl Harald




Am 04.01.21 um 20:41 schrieb Phillip Susi:

Reindl Harald writes:


i have seen "user manager" instances hanging for way too long and way
more than 3 minutes over the last 10 years


The default timeout is 3 minutes iirc, so at that point it should be
forcibly killed.


i have seen often enough more than one user-manager instance and the 
total wait was way longer then the configured timeout - no matter why


and if it comes to dependencies the 3 minutes get multiplied easily when 
more than one service is running into the tmeout and waitung for each other


frankly, i had cases where i was tempted to plug the power becaus eof 
endless wait


however, it simply makes sense to have a different timeout at 
emegergency shutdown and if it only ensures that important services even 
get the change to shutdown cleanly in their dependency chain before 
power goes away

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


Re: [systemd-devel] Is LTO worth it?

2021-01-13 Thread Reindl Harald




Am 11.01.21 um 16:05 schrieb Michael Biebl:

Am Mo., 11. Jan. 2021 um 15:42 Uhr schrieb Reindl Harald
:

it shouldn't if properly used - means param with cpu-cores, just -flto
alone is terrible slow

-flto=%(nproc)
%{__make} %{?_smp_mflags}


The package uses meson's -Db_lto=true


export LDFLAGS="-Wl,--as-needed -Wl,-z,now -Wl,-z,relro -pie %{optflags} 
-flto=%(nproc)"

%meson

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


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

2021-01-13 Thread Reindl Harald



Am 04.01.21 um 16:04 schrieb Ulrich Windl:

Reindl Harald  schrieb am 04.01.2021 um 14:53 in

Nachricht <49b8413f-3131-658f-e21a-a1ee448a0...@thelounge.net>:



Am 04.01.21 um 13:42 schrieb Ulrich Windl:

Germano Massullo  schrieb am 27.12.2020 um

14:26 in
Nachricht :

Good day, I recently joined apcupsd (APC UPS Power Control Daemon)
package maintainers on Fedora/CentOS/RHEL.
After a power failure, apcupsd shuts down the system with a command
almost identical to
shutdown ‑h ‑H now
Usually when you normally shutdown your system, you may notice certain
services taking too much time to terminate and triggering a timeout
value before systemd forces them to terminate. I would like to ask if
there is a way to force the system to shutdown without waiting for these
timeouts in case an emergency like a power failure.


Basically if the UPS cannot provide power for at least 3 minutes, it's

simply

the wrong UPS (IMHO)


topic missed - it makes no difference if it can hold the power 3
minutes, 3 hours or even 3 days at the point where it decides "i need to
shutdown everything because the battery goes empty"


Harald,

I did not say anything against shutting down everything. Maybe re-read


but the topic is when it's at the point that a shutdown is necessary and 
the shutdown hangs for no good reason "if the UPS cannot provide power 
for at least 3 minutes" is simply off-topic


the topic is that the shutdown needs to be finished before the UPS is 
empty even if it provided UPS power over hours before


there is nothing like "the right UPS" when the damned machine hangs 15 
minutes waiting to finish user-manager units as one well known example 
over years

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


Re: [systemd-devel] Is LTO worth it?

2021-01-13 Thread Reindl Harald




Am 11.01.21 um 18:05 schrieb Michael Biebl:

Am Mo., 11. Jan. 2021 um 16:39 Uhr schrieb Lennart Poettering
:

https://fedoraproject.org/wiki/LTOByDefault


Interestingly, that wiki page says, that LTO should produce smaller
binaries, which clearly isn't the case here.
I wonder whether the wiki is incorrect or whether this is a toolchain
issue or if this is specific to systemd
Or maybe this is Debian specific. Would be interested to see numbers
from other distros.

Concerning the build speed: I wonder whether at least disabling LTO on
our CI would make sense. We don't really care for fast/small
executables there.


it don't make sense using different flags in CI and production builds, 
especially LTO which often points out otherwise unvisible bugs

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


Re: [systemd-devel] Is LTO worth it?

2021-01-13 Thread Reindl Harald




Am 11.01.21 um 15:34 schrieb Michael Biebl:

we've been using LTO in the Debian build for as long as I can
remember, but I begin to question whether that is a good idea.
On Debian sid (gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU
Binutils for Debian) 2.35.1),
an LTO build almost takes twice as long as a no-LTO build


it shouldn't if properly used - means param with cpu-cores, just -flto 
alone is terrible slow


-flto=%(nproc)
%{__make} %{?_smp_mflags}

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


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

2021-01-13 Thread Reindl Harald




Am 04.01.21 um 20:06 schrieb Phillip Susi:


Reindl Harald writes:


topic missed - it makes no difference if it can hold the power 3
minutes, 3 hours or even 3 days at the point where it decides "i need to
shutdown everything because the battery goes empty"


It is that point that really should be at least 3 minutes before power
fails.  As long as the battery lasts for at least 3 minutes, then the
monitoring daemon should easily be able to begin the shutdown when 3
minutes remain.

I'm not sure that forcibly killing services to quickly shut down is
really much better than the sudden power loss you are trying to avoid


i have seen "user manager" instances hanging for way too long and way 
more than 3 minutes over the last 10 years


machines where a regulayr reboot normally takes 5 seconds until ping 
responds again after type "reboot"


there is a large scale between "wait virtually forever" and "quickly 
shutdown everything without any sense"




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


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

2021-01-04 Thread Reindl Harald



Am 04.01.21 um 13:42 schrieb Ulrich Windl:

Germano Massullo  schrieb am 27.12.2020 um

14:26 in
Nachricht :

Good day, I recently joined apcupsd (APC UPS Power Control Daemon)
package maintainers on Fedora/CentOS/RHEL.
After a power failure, apcupsd shuts down the system with a command
almost identical to
shutdown ‑h ‑H now
Usually when you normally shutdown your system, you may notice certain
services taking too much time to terminate and triggering a timeout
value before systemd forces them to terminate. I would like to ask if
there is a way to force the system to shutdown without waiting for these
timeouts in case an emergency like a power failure.


Basically if the UPS cannot provide power for at least 3 minutes, it's simply
the wrong UPS (IMHO)


topic missed - it makes no difference if it can hold the power 3 
minutes, 3 hours or even 3 days at the point where it decides "i need to 
shutdown everything because the battery goes empty"

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


Re: [systemd-devel] SystemD dependency problem

2020-12-28 Thread Reindl Harald



Am 22.12.20 um 14:17 schrieb Mantas Mikulėnas:
As a special case, when a target has Wants= for some unit, it will 
automatically add an After= as well. (So from your unit's point of view, 
you have [Install] WantedBy=network-online.target, so you can imagine 
that you automatically have a Before=network-online.target as well – 
unless you explicitly specify the opposite.)


when it's part of "network-online.target" what is wrong in that case it 
hardly can have a implicit "Before=network-online.target"


"it will automatically add an After=" at the same time as "automatically 
have a Before=" is simply impossible


However, Docker has "After=network-online.target", so you end up 
creating an ordering loop


that is the problem

"WantedBy=multi-user.target" is the right thing for nearly all units 
unless you know exactly what you are doing and why

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


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

2020-12-28 Thread Reindl Harald



Am 27.12.20 um 15:40 schrieb Andrei Borzenkov:

27.12.2020 17:00, Reindl Harald пишет:



Am 27.12.20 um 14:43 schrieb Andrei Borzenkov:

27.12.2020 16:26, Germano Massullo пишет:

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



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

systemctl --force poweroff


but that is only a part of the solution because normally most services
don't take long to stop and they should be normally stopped whenever
possible

the real solution would a option to reduce the timeouts

systemctl --timeout=5 poweroff


sytemctl does not have this option


that's why i said "the real solution would be a option"
--force is not much better than a hard poweroff
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


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

2020-12-28 Thread Reindl Harald




Am 24.12.20 um 11:38 schrieb John:

On Thu, Dec 24, 2020 at 3:29 AM Andrei Borzenkov  wrote:


On Thu, Dec 24, 2020 at 5:48 AM John  wrote:


I need to have the following start
/usr/lib/systemd/user/pulseaudio.service so it can make use of
pulseaudio.  Using a After= or Wants= does not work.  What is the
correct way to have a system service like this run a user service
unit?



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


Thank you for the reply.  There are security risks running pulseaudio
in system mode[1].  


there are not unless different users using the same machine at the same 
time and it's the way to go if you as example have running mpd (music 
player daemon) 365/24 before you even login



1. 
https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/WhatIsWrongWithSystemWide/
2. 
https://lists.freedesktop.org/archives/systemd-devel/2020-December/045713.html


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


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

2020-12-28 Thread Reindl Harald



Am 27.12.20 um 14:43 schrieb Andrei Borzenkov:

27.12.2020 16:26, Germano Massullo пишет:

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



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

systemctl --force poweroff


but that is only a part of the solution because normally most services 
don't take long to stop and they should be normally stopped whenever 
possible


the real solution would a option to reduce the timeouts

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


Re: [systemd-devel] SystemD dependency problem

2020-12-28 Thread Reindl Harald




Am 22.12.20 um 12:17 schrieb Ronald Wimmer:
On a server running OL 7.9 with SystemD 219 we have a custom SystemD 
service we have something like



[Unit]
Requires=network.target docker.service

[Service]
Restart=always
RestartSec=10
TimeoutSec=300
WorkingDirectory=/data/someapplication
ExecStartPre=
ExecStart=
ExecStop=
ExecStopPost=

[Install]
WantedBy=network-online.target

which does not work. This service leads do several other services 
(rsyslogd, docker, network-online.target, ...) to be stuck in "start 
waiting".


My question is why? Is there any obvious misconfiguration in the service 
above I am too blind to see?


I would highly appreciate any hints!


besides that you lack any After/Before you really don't want to be a 
service part of "network-online.target" unless you really know what you 
are doing


too much other stuff depends on networking and with "docker.service" 
which pretty sure itself depends on networking you create a cycle


- WantedBy=network-online.target
+ WantedBy=multi-user.target
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


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

2020-12-21 Thread Reindl Harald




Am 14.12.20 um 17:22 schrieb John:

Thank you for the reply, Colin.  I found that to be the case[1].  I
think everything is working as expected now.  I still have quirks with
the kodi-x11.service since it has to call xinit as well as the kodi
binary but I do not know of a cleaner way to do it unless there is a
multiple unit solution to be had (one for xserver and another for
kodi).


targets and dependencies maybe are your friend

[root@srv-rhsoft:~]$ cat /etc/systemd/system/vmware-guest.target
[Unit]
Description=VMware Guest Group
After=vmware.service vmware-modules.service vmware.target 
vmware-vmnet.service network-up.service
Requires=vmware.service vmware-modules.service vmware.target 
vmware-vmnet.service

Wants=network-up.service
Wants=guest-arrakis.service
Wants=guest-testserver.service
Wants=guest-esxi.service

[Install]
WantedBy=multi-user.target


1. 
https://github.com/graysky2/kodi-standalone-service/commit/909f274d6eaf011add6326b28b42fecb9123c7df

On Mon, Dec 14, 2020 at 11:12 AM Colin Guthrie  wrote:


John wrote on 14/12/2020 12:52:

Note that it looks
like I will need to add some udev rules to allow the kodi user to
shutdown the system which it could do when the PAMName=login was
present.


Just a small hint, but it might be policykit rules you need to add
rather than udev rules.

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


Re: [systemd-devel] Help with Systemd + Apache 2.4 - CentOS 7

2020-11-23 Thread Reindl Harald




Am 23.11.20 um 02:32 schrieb Lucas Possamai:

Hi,

I have Apache 2.4.6-93 running on a CentOS 7.8.2003 that is not starting 
using Systemd.


If I do: /systemctl start httpd/, I get the following error:

Nov 22 20:14:11 localhost systemd[1]: Failed to start The Apache
HTTP Server.
-- Subject: Unit httpd.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel


this is outdated for years and was always wrong


-- Unit httpd.service has failed.
--
-- The result is failed.


However, running 'httpd -k start' works!

/usr/lib/systemd/system/httpd.service:

[Unit]
Description=The Apache HTTP Server
After=network.target remote-fs.target nss-lookup.target
Documentation=man:httpd(8)
Documentation=man:apachectl(8)

[Service]
Type=notify
EnvironmentFile=/etc/sysconfig/httpd
ExecStart=/usr/sbin/httpd $OPTIONS -k start
ExecReload=/usr/sbin/httpd $OPTIONS -k graceful
ExecStop=/bin/kill -WINCH ${MAINPID}
KillSignal=SIGCONT
PrivateTmp=true

[Install]
WantedBy=multi-user.target


What could it be?
who knows - look at the httpd errorlog or at least "systemctl status 
httpd.service"


however, systemd is only the messenger
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Help with Systemd + Apache 2.4 - CentOS 7

2020-11-23 Thread Reindl Harald




Am 23.11.20 um 11:22 schrieb Michael Biebl:

Am Mo., 23. Nov. 2020 um 02:33 Uhr schrieb Lucas Possamai
:


Hi,

I have Apache 2.4.6-93 running on a CentOS 7.8.2003 that is not starting using 
Systemd.

If I do: systemctl start httpd, I get the following error:

Nov 22 20:14:11 localhost systemd[1]: Failed to start The Apache HTTP Server.
-- Subject: Unit httpd.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit httpd.service has failed.
--
-- The result is failed.


However, running 'httpd -k start' works!

/usr/lib/systemd/system/httpd.service:

[Unit]
Description=The Apache HTTP Server
After=network.target remote-fs.target nss-lookup.target
Documentation=man:httpd(8)
Documentation=man:apachectl(8)

[Service]
Type=notify


Are you sure that apache2 supports sd_notify?


surely, at least the binaries from CentOS/Redhat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


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

2020-11-17 Thread Reindl Harald




Am 14.11.20 um 21:29 schrieb Vito Caputo:

[Journal]
SystemMaxUse=300M



One thing to consider is journald allocates space per-file in 8MiB
increments.

On my laptop for example, there are 27 user journals, 8MiB each, where
the last object offset is around 2MiB.  This alone burns ~162MiB in
allocated but unused space.

We should probably have some lower level tooling for scrutinizing the
journal files and reporting how much of the space is actually used vs.
fallocated.


yaeh, i own "full blown" setups using 500 MB for the OS and the complete 
workload.

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


Re: [systemd-devel] Workaround for system upgrade bug suggestions

2020-11-05 Thread Reindl Harald



Am 03.11.20 um 14:56 schrieb Barry:

On 3 Nov 2020, at 12:39, Colin Guthrie  wrote:

Barry wrote on 02/11/2020 22:20:

What is the work around until the bug is fixed?


I'd imagine you could just disable lingering for the users in question
before running the dnf upgrade command? Not ideal but it's a workaround
as you asked!



Yep I guessed that would be the only thing to do.

How do I get a list of all users with linger enabled?


look in "/var/lib/systemd/linger"
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemctl reboot/halt with non-privilege user

2020-11-05 Thread Reindl Harald



Am 28.10.20 um 12:40 schrieb An Liu:

Hi, folks,

I used to type systemctl reboot with non-privileged users, and to my 
surprise, the system goes down for the reboot.


I've tested in both debian and centos 7, they act the same, however, 
systemctl halt will prompt you to enter administrator password to continue.


which shows it's configureable

Is it default behavior by design? I dont think a non-privileged user 
could reboot the system as he/she wishes.


btw, I'm in an HPC related domain, if this behavior of systemctl is 
allowed, every single user could reboot the whole cluster as they wish, 
it's a disaster.


https://bbs.archlinux.org/viewtopic.php?id=152565
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Suppressing spam error messages in the system journal

2020-10-23 Thread Reindl Harald




Am 22.10.20 um 21:45 schrieb fox:



While it may be
true that "frontends" might provide some filtering (rsyslog, plenty of
options, journalctl much less)


in COCKPIT that filtering is easy, effective and intuitive to perform


well, us greybeards don't need handholding for configure machines as we 
don't need to be told what we have to log or not and how we dispaly it :-)

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


Re: [systemd-devel] Suppressing spam error messages in the system journal

2020-10-22 Thread Reindl Harald




Am 22.10.20 um 16:55 schrieb Dave Howorth:

On Thu, 22 Oct 2020 15:27:58 +0200
Reindl Harald  wrote:

Am 22.10.20 um 12:59 schrieb Lennart Poettering:

On Do, 22.10.20 11:11, David C. Partridge
(david.partri...@perdrix.co.uk) wrote:

1) Is there any way in journald.conf to perform a
message

suppression

similar to the one I used for syslog? If not should there be
one?
  

No.


Does that mean no there isn't and also that there should not be,
or are you open to considering allowing a suppression mechanism
similar to that available in rsyslogd?


Not a fan of such hacks. Fix the programs or filter during display,
don't suppress at time of collection.


it's not a matter of fan or not

it just makes sense to filter out things one *never* want to see at
all instead store it


I think Lennart's point is that whatever happened to cause something in
the system to make a log entry happened, and that should be recorded.
Even though you may never want to see such evidence somebody, somewhere
might want it as part of an investigation, so it's better that it's
captured and preserved. The space will eventually be reclaimed so
there's no harm done.

And as he suggests, if you never want to see it, then filter it out on
display.


different mindshapes which shouldn't even need a long discussion, there 
are people with different preferences and it's not too hard to implement 
a filter


nobody needs to use it
it's not in use as default

i personally hate it that i have to apply filters at display time again 
and again for stuff i don't care about


a lot fo software logs informational stuff nobody cares most of the time 
and all that noise burries rellay relevant stuff - in the best case i 
don't see anything at all in logs which don't need attention


again: if there is a config everyone is happy

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


Re: [systemd-devel] Suppressing spam error messages in the system journal

2020-10-22 Thread Reindl Harald




Am 22.10.20 um 12:59 schrieb Lennart Poettering:

On Do, 22.10.20 11:11, David C. Partridge (david.partri...@perdrix.co.uk) wrote:


1) Is there any way in journald.conf to perform a message

suppression

similar to the one I used for syslog? If not should there be one?



No.


Does that mean no there isn't and also that there should not be, or are you
open to considering allowing a suppression mechanism similar to that
available in rsyslogd?


Not a fan of such hacks. Fix the programs or filter during display,
don't suppress at time of collection.


it's not a matter of fan or not

it just makes sense to filter out things one *never* want to see at all 
instead store it

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


Re: [systemd-devel] How to reply to the list

2020-10-01 Thread Reindl Harald


Am 01.10.20 um 09:31 schrieb Lennart Poettering:
> On Mi, 30.09.20 11:08, Reindl Harald (h.rei...@thelounge.net) wrote:
> 
>> Am 30.09.20 um 09:35 schrieb Ulrich Windl:
>>>>>> Dave Howorth  schrieb am 28.09.2020 um 16:34 in
>>> Nachricht <20200928153422.6bf6e...@acer-suse.lan>:
>>>> On Mon, 28 Sep 2020 14:10:38 +0200
>>>> Reindl Harald  wrote:
>>>>> can you stop "reply‑all" and breaking threads when respond to lists?
>>>>
>>>> I can't answer for the reply‑all, that would annoy me as well.
>>>> But the thread isn't broken, my MUA is showing it nicely.
>>>
>>> Also: Some MUAs only have "reply" and "Reply to all"; the first one would 
>>> only
>>> reply to the sender, and the last one would reply to list and sender.
>>
>> and?
>>
>> you are one of the "reply-all" guys and so i need "reply-all" too - now
>> look at my message - do you see anything else then
>> "systemd-devel@lists.freedesktop.org"
>>
>> it's no rocket science using a 08/15 brain and remove useless RCPT's
>> even before start writing the response
> 
> Reindl, stop this. No need to write stuff about "08/15 brains".
> 
> emails are a tool, and a tool that is used a certain way by
> people. Insisting that the tool shouldn't be used that way is
> pointless. We want to discuss systemd on this mailing list and not
> what the truest bestest way to send mails to mailing lists is, it's
> irrelevant, we better adjust the mailing list so that it works for
> people rather than insist that they are doing it wrong.
> 
> Mailing lists have a high threshold of entry anyway, and scare many
> people away who aren't that used how the 1990's Internet wanted things
> to work. There's really no point in making the level of expertise you
> need to participate even higher by requiring them to use a UNIX nerd
> quality MUA.
> 
> Hence, this is a pointless discussion. What people actually do
> matters, and what the book says doesn't.

yeah, because you are one of the guys and that's why you would have got
a vacation replky until yesterday while list messages are ignored
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Antw: Re: Antw: [EXT] Re: Memory in systemctl status

2020-09-30 Thread Reindl Harald



Am 30.09.20 um 11:04 schrieb Ulrich Windl:
>>>> Reindl Harald  schrieb am 30.09.2020 um 10:56 in
> Nachricht :
> 
>>
>> Am 30.09.20 um 09:06 schrieb Ulrich Windl:
>>>> my webserver is killed because it served at monday, tuesday, thursday
>>>> and friday 4 different files with 2 GB?
>>>
>>> cgroups is for limiting resources, not for killing processes AFAIK
>>
>> [Service]
>> MemoryMax=4G
>>
>> would call OOM killer
> 
> Are you sure? I thought OOM is called when the _system_ memory is exhausted.
> IMHO any memory allocation request to the process will be denied, but the
> process wouldn't be killed. But agreed, I didn't track the cgroups changes in
> the last few years.

hell yes i am sure beause the line is from the development machine of my
co-worker who managed an andless recursion in a php script eating a
piece of memory on each iteration

after adding that httpd.service got killed by OOM killer instead bring
the whole machine with 16 GB down
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] How to reply to the list

2020-09-30 Thread Reindl Harald


Am 30.09.20 um 09:35 schrieb Ulrich Windl:
>>>> Dave Howorth  schrieb am 28.09.2020 um 16:34 in
> Nachricht <20200928153422.6bf6e...@acer-suse.lan>:
>> On Mon, 28 Sep 2020 14:10:38 +0200
>> Reindl Harald  wrote:
>>> can you stop "reply‑all" and breaking threads when respond to lists?
>>
>> I can't answer for the reply‑all, that would annoy me as well.
>> But the thread isn't broken, my MUA is showing it nicely.
> 
> Also: Some MUAs only have "reply" and "Reply to all"; the first one would only
> reply to the sender, and the last one would reply to list and sender.

and?

you are one of the "reply-all" guys and so i need "reply-all" too - now
look at my message - do you see anything else then
"systemd-devel@lists.freedesktop.org"

it's no rocket science using a 08/15 brain and remove useless RCPT's
even before start writing the response
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Antw: [EXT] Re: Memory in systemctl status

2020-09-30 Thread Reindl Harald



Am 30.09.20 um 09:11 schrieb Ulrich Windl:
>>>> Reindl Harald  schrieb am 28.09.2020 um 11:37 in
>> httpd don't use 8.7 GB RAM - period
> 
> Are you really sure about that? 

1000% sure

even if one makes the mistake and multiply the shared opcache of 400 MB
with the count of worker processes we won't exceed 4500 MB

> I haven't checked apache recently, but years
> ago, static content was memory-mapped for performance reasons.

and you think that mapping is forever long after the request is finished
or even unconditional?

https://httpd.apache.org/docs/2.4/en/mod/core.html#enablemmap

however, the config fro at least a decade:

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


Re: [systemd-devel] Antw: [EXT] Re: Memory in systemctl status

2020-09-30 Thread Reindl Harald



Am 30.09.20 um 09:06 schrieb Ulrich Windl:
>> my webserver is killed because it served at monday, tuesday, thursday
>> and friday 4 different files with 2 GB?
> 
> cgroups is for limiting resources, not for killing processes AFAIK

[Service]
MemoryMax=4G

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


Re: [systemd-devel] Memory in systemctl status

2020-09-28 Thread Reindl Harald



Am 28.09.20 um 19:32 schrieb Dave Howorth:
>> the far slower copy from the list-server is silently purged by
>> intention to avoid receive ever ymessage twice on mailing lists where
>> people can't handle a MUA
> 
> Well then, it's not Benjamin breaking the threading, it's you :P
> You need to rewrite your processing rules to prefer the list copy

how should the mail server supressing duplicates by intention smell that
the first message is a off-list copy?

* it's received
* it's stored
* later another with the same message ID arrives
* the later one is supressed

> Assuming Tbird is capable; else change your MUA.

not everyone is poor soul relying on client side rules, not for filter
duplicates and not for move messages in subfolders, that's what
mailservers are supposed to do so that the processing is independent
from the device in your hands

maybe Benjamin should switch the MUA or configure it correctly so that
he have a "reply-list" button which is based on the list headers

if he can't or don't want he can just delete everything but the list
address after "reply-all" as i did when respond to his messages
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Memory in systemctl status

2020-09-28 Thread Reindl Harald


Am 28.09.20 um 18:33 schrieb Lennart Poettering:
> On Mo, 28.09.20 14:22, Reindl Harald (h.rei...@thelounge.net) wrote:
> 
>> honestly: do you realize that i know very well how the memory management
>> of Linux works and that it's pretty fine but not part of the topic at all?
> 
> Reindl, did you see who you are replying to here? 

surely, that's why i tried to make clear that i don't need any education
about the memory management of the Linux kernel, *it's not* topic at all

> Maybe don't try to
> argue with Linus' second-in-command about what Linux memory management
> doesn't or does do

i don't and didn't ever

hell: the Linux memory management *is not* part of the discussion, it's
about what *you* show in systemd and given that htop can easily distinct
between VIRT/RES/SHARED i expect that systemd could also display proper
values without cache

i don't give a fuck about 12Gi *systemwide cache* which is a large part
of the 8.5GB you are showing fro httpd.service, it makes sense to
display that as *additional info* but not saying "that's the memory used
by this service"

[root@arrakis:~]$ systemctl status httpd.service
● httpd.service - Apache Webserver
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled;
vendor preset: disabled)
  Drop-In: /etc/systemd/system/httpd.service.d
   └─lockdown.conf
   Active: active (running) since Sun 2020-09-20 07:53:39 CEST; 1 weeks
1 days ago
  Process: 2456787 ExecReload=/usr/sbin/httpd $OPTIONS -k graceful
(code=exited, status=0/SUCCESS)
 Main PID: 713 (httpd)
Tasks: 16 (limit: 1024)
   Memory: 8.5G

[root@arrakis:~]$ free
  totalusedfree  shared  buff/cache
available
Mem:   15Gi   2.3Gi   361Mi   206Mi12Gi
   12Gi
Swap:0B  0B  0B

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


Re: [systemd-devel] Memory in systemctl status

2020-09-28 Thread Reindl Harald



Am 28.09.20 um 16:34 schrieb Dave Howorth:
> On Mon, 28 Sep 2020 14:10:38 +0200
> Reindl Harald  wrote:
>> can you stop "reply-all" and breaking threads when respond to lists?
> 
> I can't answer for the reply-all, that would annoy me as well.
> But the thread isn't broken, my MUA is showing it nicely.

hardly when the off-list copy is faster (and contains no list-headers)
and i need to reply-all and manually only keep the list because my
"reply-list" button is gone

the far slower copy from the list-server is silently purged by intention
to avoid receive ever ymessage twice on mailing lists where people can't
handle a MUA

anyways, i am more shocked that the only people replyign don#t
understand the simle fact that "Memory: 500 MB / 8.5 GB (with caches)"
would make sense but not "Memory: 8.5 GB" as the only RAM dependent output
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Memory in systemctl status

2020-09-28 Thread Reindl Harald
honestly: do you realize that i know very well how the memory management
of Linux works and that it's pretty fine but not part of the topic at all?

Am 28.09.20 um 14:08 schrieb Greg KH:
> How do you know this?  And why wouldn't they be "charged" to the task
> that caused the cache to fill up?  What "should" they do?

it's memory the OS is using and not httpd

> If you don't like the current way that Linux manages memory resources
> like this, please discuss it with the kernel developers

the way Linux manages memory is perfect

> there's not
> much that systemd can do about it, right?

surely, display what is truly used by the processes in the cgroup wich
are currently 11 workers with around 40-80 MB and so we are at around
900 MB plus some shared memory for opcache

> Why shouldn't httpd use all the ram it was allowed to, if possible?
> What's wrong with that happening if the kernel is still caching those
> resources?

NOTHING IS WRONG by the kernel caching, but it's wrong to have only
*one* memory output in "systemctl status" pretending the service is
actively using 8 GB which it don't

> If you want to tell httpd to "flush the data from the kernel" after it
> is done downloading that ISO image, please modify httpd to do so,
> otherwise how is the kernel to know that it isn't to be asked for again
> within the next minute or so?

nobody is asking the kernel to flush caches
the kernel is pretty fine

systemctl is wrong by showing a pointless value

it maybe is a *nice additional* information but *not* the value one
cares for when it's the one and only memory output

> memory management is hard :)

the memory management is fine, the output of systemctl is wrong

>> the only interesting memory is RES of all the processes
> 
> Interesting to whom?

to the admin looking which service is using how much memory and when you
have a machine with 200 GB RAM running httpd on a large system for weeks
pretending it's using 190 GB RAM is pointless

this is *not* active memory used by the process and even if it's showing
100% memory usage in that output you can still start a process
allocating 20 GB RAM without any issue

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


Re: [systemd-devel] Memory in systemctl status

2020-09-28 Thread Reindl Harald
can you stop "reply-all" and breaking threads when respond to lists?

Am 28.09.20 um 13:55 schrieb Benjamin Berg:
> On Mon, 2020-09-28 at 11:37 +0200, Reindl Harald wrote:
>>
>> Am 28.09.20 um 11:19 schrieb Benjamin Berg:
>>>> if i would set "MemoryMax" to 4G "Memory: 8.6G" would kill it
>>>> when the
>>>> caches are accounted in that context
>>>
>>> No, the kernel kicks in and reclaims memory at that point. Which can
>>> mean either swapping or just dropping caches.
>>
>> caches have *nothing* to do with the service itself
> 
> They really do. Try running multiple concurrent services that are
> actually competing for limited memory resources. Caches are only boring
> as long as you have plenty of extra memory available so that there is
> no competition for it.

and?

>>> It really sounds to me like ulimit fits better what you are trying to
>>> do. That is available through Limit*=, see systemd.exec.
>>
>> hell first i want a output in "systemctl status whatever" which is true
>> and don't contain a ISO image downloaded by someone two days ago
> 
> The output does not match your expectation. But that really doesn't
> mean it is false. If you really want more detail, then have a look at
>   /sys/fs/cgroup/system.slice/httpd.service/memory.stat
> but
>   /sys/fs/cgroup/system.slice/httpd.service/memory.current
> really is important. It is the one that tells you how much system
> memory is used by the kernel to keep the service running.

9191358464

that cache part contains downloads from a week ago which are not freed
because there is no reason, the kernel even uses that cache when a
cronjob or wahtever other service / process is doing something with that
files

pretend it's used by httpd.service in the output is completly wrong,
"Memory: 8.5G" is wrong, plain wrong

the service is using what htop shows

/sys/fs/cgroup/system.slice/httpd.service/memory.current maybe nice an
additional output, but pretend that's the memory the service is using is
wrong

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


Re: [systemd-devel] Memory in systemctl status

2020-09-28 Thread Reindl Harald


Am 28.09.20 um 11:19 schrieb Benjamin Berg:
>> if i would set "MemoryMax" to 4G "Memory: 8.6G" would kill it when the
>> caches are accounted in that context
> 
> No, the kernel kicks in and reclaims memory at that point. Which can
> mean either swapping or just dropping caches.

caches have *nothing* to do with the service itself

> It really sounds to me like ulimit fits better what you are trying to
> do. That is available through Limit*=, see systemd.exec.

hell first i want a output in "systemctl status whatever" which is true
and don't contain a ISO image downloaded by someone two days ago

not more and not less

httpd don't use 8.7 GB RAM - period

the only interesting memory is RES of all the processes

my Firefox on the desktop don't use 32 GB RAM even when VIRT shows that
and even if the latest download of a 10 GB file is somewhere in the OS
caches in case it's opened later - it's *free* memory

 Main PID: 713 (httpd)
Tasks: 16 (limit: 1024)
   Memory: 8.7G
  CPU: 2h 24min 14.348s
   CGroup: /system.slice/httpd.service
   ├─713 /usr/sbin/httpd -D FOREGROUND
   ├─2435242 /usr/sbin/httpd -D FOREGROUND
   ├─2435243 /usr/sbin/httpd -D FOREGROUND
   ├─2435931 /usr/sbin/httpd -D FOREGROUND
   ├─2435942 /usr/sbin/httpd -D FOREGROUND
   ├─2435944 /usr/sbin/httpd -D FOREGROUND
   ├─2435947 /usr/sbin/httpd -D FOREGROUND
   ├─2435948 /usr/sbin/httpd -D FOREGROUND
   ├─2435952 /usr/sbin/httpd -D FOREGROUND
   ├─2435954 /usr/sbin/httpd -D FOREGROUND
   ├─2435960 /usr/sbin/httpd -D FOREGROUND
   ├─2435966 /usr/sbin/httpd -D FOREGROUND
   ├─2435968 /usr/sbin/httpd -D FOREGROUND
   ├─2435969 /usr/sbin/httpd -D FOREGROUND
   ├─2435970 /usr/sbin/httpd -D FOREGROUND
   └─2435972 /usr/sbin/httpd -D FOREGROUND
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Memory in systemctl status

2020-09-28 Thread Reindl Harald



Am 28.09.20 um 10:37 schrieb Tomasz Torcz:
> On Mon, Sep 28, 2020 at 10:08:15AM +0200, Reindl Harald wrote:
>> Am 27.09.20 um 23:39 schrieb Benjamin Berg:
>>>>>> however, that value makes little to no sense and if that's the same
>>>>>> value as accounted for "MemoryMax" it's plain wrong
>>> But it does make sense. File caches are part of the working set of
>>> memory that a process needs. Setting MemoryMax=/MemoryMin=
>>> limits/guarantees the size of this working set. These kinds of limits
>>> or protections would be a lot less meaningful if caches were not
>>> accounted for.
>>
>> sorry but that is complete nosense
>>
>> caches are freed as soon whatever process asks for RAM and so they are
>> *not* part of the working set
>>
>> my webserver is killed because it served at monday, tuesday, thursday
>> and friday 4 different files with 2 GB?
> 
> Why "killed", you wrote yourself caches are freed. So are they freed
> or aren't they?

if i would set "MemoryMax" to 4G "Memory: 8.6G" would kill it when the
caches are accounted in that context

why should the caches be freed as long as no other process allocates memory?

"These kinds of limits or protections would be a lot less meaningful if
caches were not accounted for" is nonsense - os caches are part of the
VFS and have nothing to do with protect from a process allocating 10 GB
private memory which can't be freed other than swap it out
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Memory in systemctl status

2020-09-28 Thread Reindl Harald



Am 27.09.20 um 23:39 schrieb Benjamin Berg:
 however, that value makes little to no sense and if that's the same
 value as accounted for "MemoryMax" it's plain wrong
> But it does make sense. File caches are part of the working set of
> memory that a process needs. Setting MemoryMax=/MemoryMin=
> limits/guarantees the size of this working set. These kinds of limits
> or protections would be a lot less meaningful if caches were not
> accounted for.

sorry but that is complete nosense

caches are freed as soon whatever process asks for RAM and so they are
*not* part of the working set

that kind of limits are completly useless when i would limit a service
to 4 GB but because it served a few million different files within the
last weeks which are accounted to it's cache and working set it's now
killed?

my webserver is killed because it served at monday, tuesday, thursday
and friday 4 different files with 2 GB?

frankly my webserver can't even do anything against caching of teh VFS
layer and is not responsible at all nor do other services

BTW: stop "reply-all" to mailing-lists
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Memory in systemctl status

2020-09-27 Thread Reindl Harald


Am 27.09.20 um 14:08 schrieb Greg KH:
> On Sun, Sep 27, 2020 at 01:41:33PM +0200, Reindl Harald wrote:
>> Memory: 8.6G
>>
>> looks like there is a large part of os-caching included where i wonmder
>> how that's done because a file can be read by muliple processes /
>> services and is hopfefully only once cached
>>
>> however, that value makes little to no sense and if that's the same
>> value as accounted for "MemoryMax" it's plain wrong
>>
>> [root@arrakis:~]$ free
>>   totalusedfree  shared  buff/cache
>> available
>> Mem:   15Gi   2.2Gi   585Mi   309Mi12Gi
>>12Gi
>> Swap:0B  0B  0B
> 
> The kernel does this, it's nothing to do with systemd or anything else.
> 
> You can get "back" that memory for a short while if you really want it
> by doing:
>   echo 3 > /proc/sys/vm/drop_caches
> 
> For more details, see https://www.linuxatemyram.com/

you completly miss the point and should not cut in the middle of a post!

Memory: 8.6G

*no* httpd don't consume 8.6GB RAM

the question is *why* systemd takes the os-cache into account of the
memory a service is using

[root@arrakis:~]$ systemctl status httpd.service
● httpd.service - Apache Webserver
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled;
vendor preset: disabled)
  Drop-In: /etc/systemd/system/httpd.service.d
   └─lockdown.conf
   Active: active (running) since Sun 2020-09-20 07:53:39 CEST; 1 weeks
0 days ago
  Process: 1935633 ExecReload=/usr/sbin/httpd $OPTIONS -k graceful
(code=exited, status=0/SUCCESS)
 Main PID: 713 (httpd)
Tasks: 17 (limit: 1024)
   Memory: 8.6G
  CPU: 2h 8min 5.442s
   CGroup: /system.slice/httpd.service
   ├─713 /usr/sbin/httpd -D FOREGROUND
   ├─2151772 /usr/sbin/httpd -D FOREGROUND
   ├─2151803 /usr/sbin/httpd -D FOREGROUND
   ├─2151805 /usr/sbin/httpd -D FOREGROUND
   ├─2152130 /usr/sbin/httpd -D FOREGROUND
   ├─2152132 /usr/sbin/httpd -D FOREGROUND
   ├─2152188 /usr/sbin/httpd -D FOREGROUND
   ├─2152189 /usr/sbin/httpd -D FOREGROUND
   ├─2152199 /usr/sbin/httpd -D FOREGROUND
   ├─2152211 /usr/sbin/httpd -D FOREGROUND
   ├─2152213 /usr/sbin/httpd -D FOREGROUND
   ├─2152214 /usr/sbin/httpd -D FOREGROUND
   ├─2152215 /usr/sbin/httpd -D FOREGROUND
   ├─2152217 /usr/sbin/httpd -D FOREGROUND
   ├─2152220 /usr/sbin/httpd -D FOREGROUND
   ├─2152756 /usr/sbin/httpd -D FOREGROUND
   └─2152886 /usr/sbin/httpd -D FOREGROUND
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] Memory in systemctl status

2020-09-27 Thread Reindl Harald
Memory: 8.6G

looks like there is a large part of os-caching included where i wonmder
how that's done because a file can be read by muliple processes /
services and is hopfefully only once cached

however, that value makes little to no sense and if that's the same
value as accounted for "MemoryMax" it's plain wrong

[root@arrakis:~]$ free
  totalusedfree  shared  buff/cache
available
Mem:   15Gi   2.2Gi   585Mi   309Mi12Gi
   12Gi
Swap:0B  0B  0B

[root@arrakis:~]$ systemctl status httpd.service
● httpd.service - Apache Webserver
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled;
vendor preset: disabled)
  Drop-In: /etc/systemd/system/httpd.service.d
   └─lockdown.conf
   Active: active (running) since Sun 2020-09-20 07:53:39 CEST; 1 weeks
0 days ago
  Process: 1935633 ExecReload=/usr/sbin/httpd $OPTIONS -k graceful
(code=exited, status=0/SUCCESS)
 Main PID: 713 (httpd)
Tasks: 17 (limit: 1024)
   Memory: 8.6G
  CPU: 2h 8min 5.442s
   CGroup: /system.slice/httpd.service
   ├─713 /usr/sbin/httpd -D FOREGROUND
   ├─2151772 /usr/sbin/httpd -D FOREGROUND
   ├─2151803 /usr/sbin/httpd -D FOREGROUND
   ├─2151805 /usr/sbin/httpd -D FOREGROUND
   ├─2152130 /usr/sbin/httpd -D FOREGROUND
   ├─2152132 /usr/sbin/httpd -D FOREGROUND
   ├─2152188 /usr/sbin/httpd -D FOREGROUND
   ├─2152189 /usr/sbin/httpd -D FOREGROUND
   ├─2152199 /usr/sbin/httpd -D FOREGROUND
   ├─2152211 /usr/sbin/httpd -D FOREGROUND
   ├─2152213 /usr/sbin/httpd -D FOREGROUND
   ├─2152214 /usr/sbin/httpd -D FOREGROUND
   ├─2152215 /usr/sbin/httpd -D FOREGROUND
   ├─2152217 /usr/sbin/httpd -D FOREGROUND
   ├─2152220 /usr/sbin/httpd -D FOREGROUND
   ├─2152756 /usr/sbin/httpd -D FOREGROUND
   └─2152886 /usr/sbin/httpd -D FOREGROUND
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] 99-default.link which such a high number ?

2020-09-25 Thread Reindl Harald



Am 25.09.20 um 16:46 schrieb Francis Moreau:
> I want to override /usr/lib/systemd/network/99-default.link so I need
> to create a file starting with "99-" prefix.
> 
> This doesn't seem logical to me because the numbers are supposed to
> encode the priority however nothing is left to the user if the
> defaults used is 99.
> 
> I find more logical for the defaults to use a small number such as 10.
> 
> What am I missing ?

/etc/systemd/network/99-default.link
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] journald forwarding to rsyslogd. Huge (350 times) performance degradation. What am I doing wrong???

2020-09-20 Thread Reindl Harald


Am 20.09.20 um 16:09 schrieb Vitaly Repin:
> Thanks for the answer!

please avoid off-list copies and top-posting when you got an answer with
proper quoting (you break threading and produce unreadable conversations
by permanently switch between quoting styles)

> However, it looks like that imjournal module is not an option for me.
> 
> rsyslog imjournal module documentation
> (https://www.rsyslog.com/doc/v8-stable/configuration/modules/imjournal.html)
> clearly recommends to use imuxsock module in my case:
> 
> [begin quote]
> As such, the performance of a configuration utilizing this module may
> be notably slower than when using imuxsock.
> The journal provides imuxsock with a copy of all “classical” syslog
> messages, however, it does not provide structured data. '
> Only if that structured data is needed, imjournal must be used.
> Otherwise, imjournal may simply be replaced by imuxsock, and we highly
> suggest doing so.
> [end quote]
> 
> I do not need structural data and I need performance. My system
> generates a substantial amount of logs. I want to be able to store
> messages with an arrival rate of 10 000 messages per second at least.

with "Storage=volatile" there is is not space for "database corruption"
and given that it *reads* the journal on that channel is not much space
for ratelimiting unless you hit the ratelimits of journald itself

[root@srv-rhsoft:~]$ cat /etc/systemd/journald.conf
[Journal]
Storage=volatile
RateLimitInterval=1s
RateLimitBurst=2
RuntimeMaxUse=100M
ForwardToSyslog=no

>> Max rate at which log messages are NOT dropped is 17250 msg/s for logging to 
>> /run/systemd/journal/syslog.  And only 47 messages per second for logging to 
>> /dev/log.
> 
> 
> Den sön 20 sep. 2020 kl 12:26 skrev Reindl Harald :
>>
>>
>>
>> Am 20.09.20 um 12:07 schrieb Vitaly Repin:
>>
>>> ForwardToSyslog=yes
>>
>> this is long obsolete
>>
>>
>> $WorkDirectory /var/lib/rsyslog
>>
>> module(load="imjournal" StateFile="imjournal.state"
>> WorkAroundJournalBug="on" Ratelimit.Interval="600" Ratelimit.Burst="5")

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


Re: [systemd-devel] journald forwarding to rsyslogd. Huge (350 times) performance degradation. What am I doing wrong???

2020-09-20 Thread Reindl Harald



Am 20.09.20 um 12:07 schrieb Vitaly Repin:

> ForwardToSyslog=yes

this is long obsolete


$WorkDirectory /var/lib/rsyslog

module(load="imjournal" StateFile="imjournal.state"
WorkAroundJournalBug="on" Ratelimit.Interval="600" Ratelimit.Burst="5")
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Journal message timestamps

2020-09-08 Thread Reindl Harald



Am 08.09.20 um 13:06 schrieb Mark Corbin:
> Change /lib/systemd/system/fake-hwclock.service to add
> 'systemd-journald.service' to the end of the 'Before' line

this is *system* area and the admin has no business to touch anything
there as well as packages have no business to touch admin area in
/etc/systemd/system

your playground is in
/etc/systemd/system/fake-hwclock.service.d/myoverrides.conf

and yes that is important so that you don#t have to redo your changes
after each and every update and way better than cloning the whole
unit-file in /etc/systemd/system/ so that reasonable upstream changes
get applied in teh future

-

/etc/systemd/system/fake-hwclock.service.d/myoverrides.conf:

[Unit]
Before=systemd-journald.service
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Q: Start a unit n minutes after a successful boot

2020-09-08 Thread Reindl Harald



Am 08.09.20 um 09:21 schrieb Ulrich Windl:
> Configuring a new system with non-redundant system disk I'm wondering: How 
> could I start an automatic backup job that is triggered n minutes after the 
> system started

* create a own target
* order it after multi-user.target
* put a service jn there which sleeps
* after the sleep or by a service ordered after that one
  do whatever you want to do

-

that below is something similar to not break existing connections by
reboot the gateway by disable nf_conntrack_tcp_loose at boot but do it
90 seconds later, in that cae no own target needed

[root@firewall:~]$  cat /etc/systemd/system/network-up-post.service
[Unit]
Description=Network Invalid-Detection
After=network-up.service
Requires=network-online.target

[Service]
Type=oneshot
RemainAfterExit=yes
TimeoutStartSec=90
ExecStart=/usr/bin/sleep 30
ExecStart=/usr/sbin/sysctl -q -e -w net.netfilter.nf_conntrack_tcp_loose=0

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


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

2020-09-07 Thread Reindl Harald



Am 07.09.20 um 10:52 schrieb Ulrich Windl:
 Vito Caputo  schrieb am 05.09.2020 um 04:44 in 
 Nachricht
> <20200905024407.n2qy34rxqqdlv...@shells.gnugeneration.com>:
>> Could you please stop signing mails sent to this publicly accessible,
>> archived, and indexed/searchable mailing list with this impossible
>> boilerplate:
>>
>>> IMPORTANT: The contents of this email and any attachments are confidential.
>>> They are intended for the named recipient(s) only. If you have received
>>> this email by mistake, please notify the sender immediately and do not
>>> disclose the contents to anyone or make copies thereof.
> 
> Some companies require users to send such nonsense...

some people don't use such mail systems for public lists
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Antw: [EXT] Re: User/Group overrides in a templated service triggered via timer

2020-09-07 Thread Reindl Harald



Am 07.09.20 um 10:00 schrieb Ulrich Windl:
>> Anyway, long story short: you typically do not enable services that
>> are only supposed to activated by timer units, enabling those timers
>> should entirely suffice, and the timers will start the services when
>> the time comes.
> 
> Interesting: I had expected that units using a timer would not be run when
> "disabled", meaning "timer" is just a trigger, but of no unit cares...

a timer is the same trigger as "enable" and get startet as part of the
boot process

* letsencrypt.timer
* letsencrypt.service

letsencrypt.service don't even have a [Install] section and can't be
enabled at all
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd-userdbd and other stuff running all the time

2020-09-04 Thread Reindl Harald


Am 04.09.20 um 17:52 schrieb Reindl Harald:
> Am 04.09.20 um 17:37 schrieb Lennart Poettering:
>> userdbd is activated on demand and exit-on-idle btw. it exits after
>> 25s of no client making any request. if you have it running this means
>> stuff is using it.

well, tell why it is still running on a firewall machine after nearly
two minutes and eatinh 5 my RAM which is 10% of the whole system

there is *nothing* running expect a socket activated sshd and you hardly
get a simpler and smaller setup

[root@firewall:~]$ pstree
systemd─┬─2*[agetty]
├─dbus-broker-lau───dbus-broker
├─sshd───sshd───bash───pstree
├─systemd───(sd-pam)
├─systemd-journal
├─systemd-logind
├─systemd-udevd
├─systemd-userdbd───3*[systemd-userwor]
├─ulogd
├─vmtoolsd───{vmtoolsd}
└─vnstatd

[root@firewall:~]$ systemctl status systemd-userdbd.service
● systemd-userdbd.service - User Database Manager
 Loaded: loaded (/usr/lib/systemd/system/systemd-userdbd.service;
static; vendor preset: disabled)
 Active: active (running) since Fri 2020-09-04 18:10:39 CEST; 1min
39s ago
TriggeredBy: ● systemd-userdbd.socket
   Docs: man:systemd-userdbd.service(8)
   Main PID: 474 (systemd-userdbd)
 Status: "Processing requests..."
  Tasks: 4 (limit: 991)
 Memory: 4.6M
CPU: 60ms
 CGroup: /system.slice/systemd-userdbd.service
 ├─474 /usr/lib/systemd/systemd-userdbd
 ├─475 systemd-userwork
 ├─476 systemd-userwork
 └─477 systemd-userwork
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] howto switch from grub2-bios to systemd-boot

2020-09-04 Thread Reindl Harald



Am 04.09.20 um 17:44 schrieb Lennart Poettering:
> On Fr, 04.09.20 17:10, Reindl Harald (h.rei...@thelounge.net) wrote:
> 
>>> No, that's not supported in sd-boot. A boot loader is a boot loader,
>>> it should contain a fragile storage stack. It's kinda what sd-boot is
>>> supposed to do better than grub.
>>
>> well, a boot loader should just *load* and not write anything so RAID1
>> is technically no problem and it shouldn't matter which of the 1, 2, 3
>> or 4 disks is there unless one survived.
> 
> Robust boot loaders typically want to write boot counters to disk, so
> that they can automatically revert back to older versions of the
> OS/kernel if it doesn't boot. Thus some form of write access is
> necessary if you care about robustness.

well, in the past 15 years i had zero need for automagic "let us boot
the last kernel" given that ILO and VMs exists

but i had a ton of dying disks, all an RAID systems which just boot as
if nothing has happened at least when your machine is not infected with UEFI

if the system is 300 kilometers away from you i can call a trained
monkey and tell him "connect a screen and a keyboard and hit cursor down
until a menu comes and then please select the second entry"

i can't instrcut a trained monkey on a phone how to boot from a
live-media and restore the boot-loader
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd-userdbd and other stuff running all the time

2020-09-04 Thread Reindl Harald


Am 04.09.20 um 17:37 schrieb Lennart Poettering:
> On Mo, 24.08.20 13:40, Reindl Harald (h.rei...@thelounge.net) wrote:
> 
>> is taht growing amount of services running on all systems really
>> necessary and why are things like "repart.service" and "homed.service"
>> are started "static" which makes the concept of enable/disable things
>> more and more obsolete
> 
> neither userdbd nor homed are static. Just disable them if you really
> don't want them. "systemctl disable" works for them.

not for userdbd - it's fired up and eating nearly 2 MB RAM - add that on
a host with 100 vuirtual machines

> repart is conditioned out if you have no drop-ins for it. Which I
> assume you haven't. hence no need to disable it. Moreover even if you
> have drop-ins this is a oneshot service only. it runs at boot and
> exits quickly.

check a growing amount of folders and files at startup is hardly for free

[root@rawhide ~]# systemctl status systemd-repart.service
● systemd-repart.service - Repartition Root Disk
 Loaded: loaded (/usr/lib/systemd/system/systemd-repart.service; static)
 Active: inactive (dead)
  Condition: start condition failed at Fri 2020-09-04 17:42:38 CEST; 59s ago
 ├─ ConditionDirectoryNotEmpty=|/usr/lib/repart.d was not met
 ├─ ConditionDirectoryNotEmpty=|/usr/local/lib/repart.d was
not met
 ├─ ConditionDirectoryNotEmpty=|/etc/repart.d was not met
 └─ ConditionDirectoryNotEmpty=|/run/repart.d was not met

> userdbd is activated on demand and exit-on-idle btw. it exits after
> 25s of no client making any request. if you have it running this means
> stuff is using it.
> 
> userdbd provides a sandbox for NSS modules to clients that want to
> user/group lookups. the idea is that we can avoid loading network
> facing code to be loaded into each and every process that way, which
> is security-wise highly problematic.

adding more complexity to systems only using local users is also problematic

>> lrwxrwxrwx 1 root root9 2020-05-28 09:06 systemd-homed.service ->
>> /dev/null
>> lrwxrwxrwx 1 root root9 2020-07-06 17:45 systemd-repart.service ->
>> /dev/null
>> lrwxrwxrwx 1 root root9 2020-08-06 18:48 systemd-timesyncd.service
>> -> /dev/null
>> lrwxrwxrwx 1 root root9 2020-08-24 12:47 systemd-userdbd.service ->
>> /dev/null
>> lrwxrwxrwx 1 root root9 2020-08-24 12:47 systemd-userdbd.socket ->
>> /dev/null
> 
> Well knock yourself out, but masking is not necessary, you can just
> disable homed/userdbd/timesyncd if you don#t want it, and repart is
> conditioned out anyway, so masking doesn't really get you much.

well, when i see them from time to time running or in "systemd-analyze
blame" disable alone is obviously not enough
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] howto switch from grub2-bios to systemd-boot

2020-09-04 Thread Reindl Harald



Am 04.09.20 um 16:58 schrieb Lennart Poettering:
> On Mo, 22.06.20 16:01, Reindl Harald (h.rei...@thelounge.net) wrote:
> 
>> what is the best way to get a Fedora using legacy-boot to UEFI and at
>> the same time switch from grub2 to systemd-boot?
>>
>> * how to get in installed from a live-iso to
>>   the existing setup on disk
>> * how to get the config files right at the first try
>> * how does it work with kernel-updates
>> * how to get GRUB_CMDLINE_LINUX over
>> * is it possible to not kill grub2 for the time beeing
>>   to boot back into BIOS-mode in case of emergency
> 
> we should probably write this down somewhere in clean form, but
> basically what you have to do is this:
> 
> 0. Remove grub, grubby and all that stuff
> 1. Mount your ESP to /boot, /efi or /boot/efi
> 2. If you have it mount your XBOOTLDR partition to /boot (consider
>changing your partition type uuid of your pre-existing /boot
>partition to the XBOOTLDR one, if you have it)
> 3. Run "bootctl install"
> 4. Manually invoke "kernel-install add" for all kernels that are
>currently installed.
> 
> The 4th step is only necessary because the grub RPM fucks up the
> kernel-install script systemd ships and generates snippets that are
> invalid. After removing grub you thus need to rerun "kernel-install"
> to regenerate the correct snippets.
> 
> In an ideal world Fedora would just use boot loader spec compliant
> snippets anyway, so that step 4 wouldn't be ncessary. And step 1+2 would
> not be necessary either, if everything is was mounted and tagged
> properly from the beginning.
> 
> Kernel command line you can configure in /etc/kernel/cmdline. That's
> where kernel-install picks it up. When you change that file, rerun
> kernel-install for the relevant kernels.
> 
>> can /boot holding the kernel itself still be a Linux RAID1 or classical
>> ext4 partition or is it required that the kernel and initrd live on the
>> EFI partition too?
> 
> No, that's not supported in sd-boot. A boot loader is a boot loader,
> it should contain a fragile storage stack. It's kinda what sd-boot is
> supposed to do better than grub.

well, a boot loader should just *load* and not write anything so RAID1
is technically no problem and it shouldn't matter which of the 1, 2, 3
or 4 disks is there unless one survived

without having the kernel redundant a RAID setup is completly pointless
and that's why the whole UEFI stuff is broken by design as broken as
smomething can be
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


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

2020-08-29 Thread Reindl Harald


Am 29.08.20 um 19:17 schrieb Tom Browder:
> On Fri, Aug 28, 2020 at 11:12 Andrei Borzenkov  > wrote:
> 
> 28.08.2020 17:47, Tom Browder пишет:
> > I want to create a service file that has to consider other services.
> 
> ...
> 
> If you tell us what you try to achieve, someone may have an idea how
> to express it using systemd.
> 
> 
> Okay, here is my situation:
> 
> I have a single Apache2 httpd instance listening on ports 80 and 433.
> All on port 80 is forced to 433. I am running multiple SNI virtual hosts
> on the same IPv4 address via an Apache2 macro. 
> 
> The apache server is successfully handled with its systemd service file
> "apache2.service".
> 
> Some of the virtual hosts are running behind a reverse proxy and I will
> have a script that will start them all after the "apache2.service" is
> confirmed to be running.
> 
> So I need a service file called, say, "reverse-proxies.service" that would:
> 
> 1. wait for the "apache2.service" to start successfully
> 2. execute the proxy start script called, say,
> "/etc/proxy-service/start-proxy-servers"
> 3. restart the proxies after apache restarts
> 4. stop the proxies before apache stops (not strictly required)

make the script (besdies that scripts don't belong to /etc) a
oneshot-service and learn about
https://www.freedesktop.org/software/systemd/man/systemd.target.html

the probably easier option would be ExecStartPost/ExecStopPost in a
dropin in /etc/systemd/system/apache2.service.d/whatever.conf

https://coreos.com/os/docs/latest/using-systemd-drop-in-units.html

no need for books, these are basic tasks

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


Re: [systemd-devel] A sh -c '${name} and $name' are treated inconsistently within a .service unit

2020-08-27 Thread Reindl Harald



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

if you want a script just use a script and call it with ExecStart
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Antw: [EXT] Re: tmpfiles chicken-egg problem

2020-08-27 Thread Reindl Harald


Am 26.08.20 um 16:01 schrieb Ulrich Windl:
 Lennart Poettering  schrieb am 26.08.2020 um 15:40
> in
> Nachricht <20200826134031.GA257903@gardel-login>:
>> On Mi, 26.08.20 08:37, Ulrich Windl (ulrich.wi...@rz.uni‑regensburg.de)
> wrote:
>>
>>> Hi!
>>>
>>> I see this problem in SLES12 (systemd‑228‑157.12.5.x86_64): On boot systemd
> 
>> tries to use LDAP to resolve user names, resulting in an error like this:
>>> systemd‑tmpfiles: nss‑ldap: do_open: do_start_tls failed:stat=‑1
>>
>> Files and directories managed by systemd‑tmpfiles have to be owned by
>> *system* users and groups. If you declare files/dirs that are owned by
>> non‑system users, then you are on your own, and things will fall apart.
>>
>> A system user must be resolvable during the entire runtime of the
>> system, i.e. managed in /etc/passwd and /etc/group, not in LDAP.
>>
>> This is extensively documented in tmpfiles.d(5) or here:
>>
>> https://systemd.io/UIDS‑GIDS/#notes‑on‑resolvability‑of‑user‑and‑group‑names
> 
>>
>> Hence, if this happens your setup is borked in some way: some entries
>> in tmpfiles.d/ drop‑ins are owned by users/groups managed by LDAP. Fix
>> that, and everything should be fine.
> 
> It's all transitional in some way. In the past a system user was a user with a
> UID below the UIDs given to interactive users. Directories existed right from
> the beginning of the boot, and the user had to be known when a corresponding
> process had to be started. Not earlier. Systemd redefined the world, so don't
> point at the world if things are broken now...

did you skip the follow-up paragraph by intention to repeat "Systemd
redefined the world, so don't point at the world"?

just create directories when the process has to be startet eiter by
ExecStartPre or RuntimeDirectory/StateDirectory and you are done

And besides that, we actually push people towards using
RuntimeDirectory=, StateDirectory=, … and stuff so that these dirs are
created when the service is started and not earlier, for services where
that works.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] 'PIDFile=' warning and override.conf

2020-08-26 Thread Reindl Harald


Am 26.08.20 um 11:48 schrieb Richard Hector:
> On 26/08/20 9:07 pm, Reindl Harald wrote:
>>
>>
>> Am 26.08.20 um 01:26 schrieb Richard Hector:
>>> Hi all,
>>>
>>> I've got the common warning:
>>>
>>> /lib/systemd/system/fail2ban.service:12: PIDFile= references path below
>>> legacy directory /var/run/, updating /var/run/fail2ban/fail2ban.pid →
>>> /run/fail2ban/fail2ban.pid; please update the unit file accordingly.
>>>
>>> I made the change in the relevant override.conf file, but that doesn't
>>> seem to work. Changing the 'real' one in /lib/systemd/system works.
>>>
>>> Is that how it's supposed to be?
>>>
>>> I'm using debian buster, with systemd package version 241-7~deb10u4
>>
>> better writ ebugreports so that these sloppy mainatiners wake up and
>> read their own logfiles before throwing packages to users - it's the
>> same on Fedora and i simple don't get it
> 
> Which came first? The package that refers to the wrong directory, or the
> systemd version that changed the directory and/or started complaining
> about it? Debian stretch (systemd 232-25+deb9u12) doesn't complain.

besdies that /var/run is now for nearly a decade a symlink to /run (at
least on other distributions) first came systemd-232 and the complaints
long before the release and packagers/maintainers just need to read
their logfiles like you did
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] tmpfiles chicken-egg problem

2020-08-26 Thread Reindl Harald



Am 26.08.20 um 08:37 schrieb Ulrich Windl:
> I see this problem in SLES12 (systemd-228-157.12.5.x86_64): On boot systemd 
> tries to use LDAP to resolve user names, resulting in an error like this:
> systemd-tmpfiles: nss-ldap: do_open: do_start_tls failed:stat=-1
> 
> Eventually:
> systemd-tmpfiles: nss_ldap: could not search LDAP server - Server is 
> unavailable
> 
> And:
> systemd[1]: systemd-tmpfiles-setup.service: Main process exited, code=exited, 
> status=1/FAILURE
> 
> 
> Aboput 15 minutes later I see this message:
> systemd[1]: Started Cleanup of Temporary Directories.
> 
> So Cleanup succeeds while setup failed?

you confuse /tmp and /var/tmp with "systemd-tmpfiles-setup.service -
Create Volatile Files and Directories"
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] 'PIDFile=' warning and override.conf

2020-08-26 Thread Reindl Harald


Am 26.08.20 um 01:26 schrieb Richard Hector:
> Hi all,
> 
> I've got the common warning:
> 
> /lib/systemd/system/fail2ban.service:12: PIDFile= references path below
> legacy directory /var/run/, updating /var/run/fail2ban/fail2ban.pid →
> /run/fail2ban/fail2ban.pid; please update the unit file accordingly.
> 
> I made the change in the relevant override.conf file, but that doesn't
> seem to work. Changing the 'real' one in /lib/systemd/system works.
> 
> Is that how it's supposed to be?
> 
> I'm using debian buster, with systemd package version 241-7~deb10u4

better writ ebugreports so that these sloppy mainatiners wake up and
read their own logfiles before throwing packages to users - it's the
same on Fedora and i simple don't get it

beides the fact that for 99.9% pidfiles are just useless at all
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] systemd-userdbd and other stuff running all the time

2020-08-24 Thread Reindl Harald
is taht growing amount of services running on all systems really
necessary and why are things like "repart.service" and "homed.service"
are started "static" which makes the concept of enable/disable things
more and more obsolete

7.4 MB is a lot and i don't see any issue by just mask
"systemd-userdbd.service" and "systemd-userdbd.socket" on sever systems
at the moment, but who knows how deep the dependencies will become in
the future

lrwxrwxrwx 1 root root9 2020-05-28 09:06 systemd-homed.service ->
/dev/null
lrwxrwxrwx 1 root root9 2020-07-06 17:45 systemd-repart.service ->
/dev/null
lrwxrwxrwx 1 root root9 2020-08-06 18:48 systemd-timesyncd.service
-> /dev/null
lrwxrwxrwx 1 root root9 2020-08-24 12:47 systemd-userdbd.service ->
/dev/null
lrwxrwxrwx 1 root root9 2020-08-24 12:47 systemd-userdbd.socket ->
/dev/null

[root@srv-rhsoft:~]$ systemctl status systemd-userdbd
● systemd-userdbd.service - User Database Manager
 Loaded: loaded (/usr/lib/systemd/system/systemd-userdbd.service;
static; vendor preset: disabled)
 Active: active (running) since Mon 2020-08-24 12:45:34 CEST; 48min ago
TriggeredBy: ● systemd-userdbd.socket
   Docs: man:systemd-userdbd.service(8)
   Main PID: 719025 (systemd-userdbd)
 Status: "Processing requests..."
  Tasks: 4 (limit: 512)
 Memory: 7.4M
CPU: 253ms
 CGroup: /system.slice/systemd-userdbd.service
 ├─719025 /usr/lib/systemd/systemd-userdbd
 ├─725718 systemd-userwork
 ├─725842 systemd-userwork
 └─725843 systemd-userwork
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Need help with setting up systemd for Apache on Debian 10

2020-08-23 Thread Reindl Harald



Am 23.08.20 um 19:19 schrieb Tom Browder:
> There is no official Apache systemd setup for Apache from source, and
> I didn't get any help from users there. I tried to mimic a good
> solution by first installing Apache with the Debian package and
> finding all the systemd files with "httpd" or "apache" in the name.
> That resulted in the following list:
> 
> /etc/systemd/system/multi-user.target.wants/apache2.service
> /run/systemd/units/invocation:apache2.service
> /usr/lib/systemd/system/apache2.service
> /var/lib/systemd/deb-systemd-helper-enabled/apache2.service.dsh-also
> 
> /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/apache2.service
> 
> The contents of the "apache2.service" file are:
> 
> [Unit]
> Description=The Apache HTTP Server
> After=network.target remote-fs.target nss-lookup.target
> 
> [Service]
> Type=forking
> Environment=APACHE_STARTED_BY_SYSTEMD=true
> ExecStart=/usr/sbin/apachectl start
> ExecStop=/usr/sbin/apachectl stop
> ExecReload=/usr/sbin/apachectl graceful
> PrivateTmp=true
> Restart=on-abort
> 
> [Install]
> WantedBy=multi-user.target

what is your specific problem?

besdies there is no need for ExecStop at all and you can use type=simple
combined with "-D FOREGROUND"

EnvironmentFile=-/etc/sysconfig/httpd
Environment="PATH=/usr/bin:/usr/sbin"
Environment="LANG=C.UTF-8"
ExecStart=/usr/sbin/httpd $OPTIONS -D FOREGROUND
ExecReload=/usr/sbin/httpd $OPTIONS -k graceful

DUNNO what's about all that useless "deb-systemd-helper"

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


Re: [systemd-devel] fuse-sshfs and x-systemd.automount

2020-08-16 Thread Reindl Harald



Am 16.08.20 um 17:22 schrieb Lennart Poettering:
> On So, 16.08.20 17:14, Reindl Harald (h.rei...@thelounge.net) wrote:
> 
>> Am 16.08.20 um 17:03 schrieb Lennart Poettering:
>>> On Sa, 15.08.20 22:56, Reindl Harald (h.rei...@thelounge.net) wrote:
>>>
>>>> is it a bug or a concept issue that it's mounted fpr root instead auf
>>>> the user given with uid or is there just a param i am not aware
>>>> mising?
>>>
>>> I don't understand a word. What do you mean by "mounted for root"?
>>
>> i want it mounted *for my user* as when i type "mount /mnt/arrakis" as
>> my user
> 
> What does "for my user" mean? I still don't get it?
> 
> Also, aren't you using x-systemd.automount? so you want automatic
> mounting on access? But now you suggest explicit mounting by calling
> "mount"?

seriously?

i just want the same behavior as if i would mount the fuse-mounpoint as
user but without typing "mount /mnt/arrakis"

* fuse-mount as the user specified by "uid=,gid="
* not readable for other users
* just the identical behavior
* but aitomatically by *use* the mountpoint
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] fuse-sshfs and x-systemd.automount

2020-08-16 Thread Reindl Harald



Am 16.08.20 um 17:21 schrieb Lennart Poettering:
> On So, 16.08.20 17:16, Reindl Harald (h.rei...@thelounge.net) wrote:
>> Am 16.08.20 um 17:01 schrieb Lennart Poettering:
>>> On So, 16.08.20 09:05, Reindl Harald (h.rei...@thelounge.net) wrote:
>>>
>>>> how is it not given it#s a systemd-option and what is your f**
>>>> problem?
>>>
>>> Reindl, I'll put you back on moderation if you write another mail like
>>> this.
>>
>> then do the same with people provocating in the style of "how is it
>> relevant to systemd?" given that x-systemd.automount is clearly a
>> systemd option and "systemd[1]: mnt-arrakis.automount: Got automount
>> request for /mnt/arrakis," is clearly from PID1
> 
> You wrote something abut "what is your f**" problem, the person you
> responded to, didn't.

he other user was annyoed about my question and what it has to do with
systemd - nobody forced him to read or respond at all
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] fuse-sshfs and x-systemd.automount

2020-08-16 Thread Reindl Harald



Am 16.08.20 um 17:01 schrieb Lennart Poettering:
> On So, 16.08.20 09:05, Reindl Harald (h.rei...@thelounge.net) wrote:
> 
>> how is it not given it#s a systemd-option and what is your f**
>> problem?
> 
> Reindl, I'll put you back on moderation if you write another mail like
> this.

then do the same with people provocating in the style of "how is it
relevant to systemd?" given that x-systemd.automount is clearly a
systemd option and "systemd[1]: mnt-arrakis.automount: Got automount
request for /mnt/arrakis," is clearly from PID1




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


Re: [systemd-devel] fuse-sshfs and x-systemd.automount

2020-08-16 Thread Reindl Harald



Am 16.08.20 um 17:03 schrieb Lennart Poettering:
> On Sa, 15.08.20 22:56, Reindl Harald (h.rei...@thelounge.net) wrote:
> 
>> is it a bug or a concept issue that it's mounted fpr root instead auf
>> the user given with uid or is there just a param i am not aware
>> mising?
> 
> I don't understand a word. What do you mean by "mounted for root"?

i want it mounted *for my user* as when i type "mount /mnt/arrakis" as
my user
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] fuse-sshfs and x-systemd.automount

2020-08-16 Thread Reindl Harald


Am 16.08.20 um 07:51 schrieb Andrei Borzenkov:
> 15.08.2020 23:56, Reindl Harald пишет:
>> is it a bug or a concept issue that it's mounted fpr root instead auf
>> the user given with uid or is there just a param i am not aware mising?
> 
> allow_other

works, but changes the owner to root and inherits chmod 755 from the
remote diretory and so *everyone* can access it, mode is not supported

fuse: unknown option(s): `-o mode=0700'

noauto,user,rw,noexec,nosuid,nodev,noatime,uid=harry,gid=verwaltung,allow_other,x-systemd.automount

> how is it relevant to systemd?

how is it not given it#s a systemd-option and what is your f** problem?

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


[systemd-devel] fuse-sshfs and x-systemd.automount

2020-08-15 Thread Reindl Harald
is it a bug or a concept issue that it's mounted fpr root instead auf
the user given with uid or is there just a param i am not aware mising?

there are 20 mountpoints of that style and automount would be really cool

i wouldn't even mind if touching by root would mount it for mewith root
having no access as expected for fuse-mounts of that style

they are all excluded for mlocate

---

sshfs#reindl@arrakis:/ /mnt/arrakis fuse
noauto,user,rw,noexec,nosuid,nodev,noatime,uid=harry,gid=verwaltung,x-systemd.automount

---

Aug 15 22:43:46 srv-rhsoft systemd[1]: Set up automount
mnt-arrakis.automount.
Aug 15 22:43:51 srv-rhsoft systemd[1]: mnt-arrakis.automount: Got
automount request for /mnt/arrakis, triggered by 47290 (ls)
Aug 15 22:43:51 srv-rhsoft systemd[1]: Mounting /mnt/arrakis...
Aug 15 22:43:51 srv-rhsoft kernel: fuse: init (API version 7.31)
Aug 15 22:43:51 srv-rhsoft systemd[1]: Mounting FUSE Control File System...
Aug 15 22:43:51 srv-rhsoft systemd[1]: Mounted FUSE Control File System.
Aug 15 22:43:52 srv-rhsoft systemd[1]: Mounted /mnt/arrakis.

[root@srv-rhsoft:~]$ df
Dateisystem  TypGröße Benutzt Verf. Verw% Eingehängt auf
/dev/md1 ext4 29G7,6G   22G   27% /
/dev/md2 ext43,6T1,2T  2,5T   33% /mnt/data
reindl@arrakis:/ fuse.sshfs  126G 58G   68G   47% /mnt/arrakis

[harry@srv-rhsoft:~]$ df
DateisystemTyp  Größe Benutzt Verf. Verw% Eingehängt auf
/dev/md1   ext4   29G7,6G   22G   27% /
/dev/md2   ext4  3,6T1,2T  2,5T   33% /mnt/data
[harry@srv-rhsoft:~]$

---

Expected:

[harry@srv-rhsoft:~]$ df
Dateisystem  TypGröße Benutzt Verf. Verw% Eingehängt auf
/dev/md1 ext4 29G7,6G   22G   27% /
/dev/md2 ext43,6T1,2T  2,5T   33% /mnt/data
reindl@arrakis:/ fuse.sshfs  126G 58G   68G   47% /mnt/arrakis
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd-inhibit don't work

2020-08-11 Thread Reindl Harald



Am 10.08.20 um 15:37 schrieb Lennart Poettering:
> On Mo, 10.08.20 15:05, Reindl Harald (h.rei...@thelounge.net) wrote:
> 
>> well, i would expect that the reboot in the scond ssh-session is
>> refused...
>>
>> [root@master:~]$ /usr/bin/systemd-inhibit --what=shutdown --who=root
>> --why="Backup in progress" --mode=block sleep 600
>>
>> [root@master:~]$ /usr/bin/systemd-inhibit; systemctl reboot
>> WHO  UID USER PID COMMWHAT WHYMODE
>> root 0   root 569 systemd-inhibit shutdown Backup in progress block
>>
>> 1 inhibitors listed.
>> [root@master:~]$ Connection to master.thelounge.net closed by remote host.
>> Connection to master.thelounge.net closed.
>> [harry@srv-rhsoft:~]$
> 
> Root is almighty on UNIX. This also means it has the privilege to
> ignore inhibitors, and thta's what you are seeing here.

tell that namesapces and gcroups :-)

my root user when doing from a graphical session "su - root" is far away
from almighty given he inherits the dropins for display-manager.service

> There is a github issue filed asking for some mechanism to extend
> inhibitors so that root can't trivially override it, but so far this
> hasn't been implemented.
sounds good

a backupserver with the only purpose running backups is the perfect
example for "nice that you instaleld some updates, but creep away and
reboot later when i am finished, no matter who you are"

dnf in one session doing upgrades and another admin in a different one
typing reboot would be another one

no question, he should be able to enforce it no matter what but not by
accident and i have around 5 things in mind where "you don#t reboot now"
would apply
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] systemd-inhibit don't work

2020-08-10 Thread Reindl Harald
well, i would expect that the reboot in the scond ssh-session is
refused...

[root@master:~]$ /usr/bin/systemd-inhibit --what=shutdown --who=root
--why="Backup in progress" --mode=block sleep 600

[root@master:~]$ /usr/bin/systemd-inhibit; systemctl reboot
WHO  UID USER PID COMMWHAT WHYMODE
root 0   root 569 systemd-inhibit shutdown Backup in progress block

1 inhibitors listed.
[root@master:~]$ Connection to master.thelounge.net closed by remote host.
Connection to master.thelounge.net closed.
[harry@srv-rhsoft:~]$
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


  1   2   3   4   5   6   7   8   9   10   >