Re: [systemd-devel] Xorg or Wayland Environment

2021-09-21 Thread Michael Biebl
Just curious:

Can someone familiar with KDE/Plasma tell us, if they nowadays (can)
use "systemd --user" to manage a login session.


Am Di., 21. Sept. 2021 um 12:52 Uhr schrieb Ed Greshko :
>
> On 21/09/2021 18:20, Colin Guthrie wrote:
> > Ed Greshko wrote on 19/09/2021 12:11:
> >> OK..
> >>
> >> I think I see the problem now.  I don't need Environment=.  But the issue 
> >> is that, I assumed, "plasma-core.target" would be
> >> reached only after a user logged in to plasma.
> >>
> >> I was wrong and the user's service is run earlier when the login screen 
> >> appears.
> >
> > I'm slightly confused by the logic here. Why is a user's systemd even 
> > running before they've logged in? If the user has lingering enabled, then 
> > it might have a systemd instance from that, but it certainly shouldn't 
> > reach any plasma-core.target as the login GUI should be running as a 
> > different user to your user I would have thought?
> >
> > e.g. under gnome, the login GUI runs as the "gdm" user. That user has a 
> > systemd --user instance, and runs various things but only once a real user 
> > has logged in will it's own systemd instance start and reach the 
> > appropriate targets.
> >
> >> I need to find a way such that the service only runs when a user logs on 
> >> to the plasma GUI.
> >
> > It seems a bit odd to me that your users' plasma-core.target has been run 
> > when your user hasn't even logged in yet. I think something is odd there, 
> > possible combined with user lingering and perhaps plasma-core being the 
> > default target for your user when it shouldn't be...
> >
> > Hope this helps you debug things.
>
> Yes, that helped.
>
> plasma-core.target isn't the correct target.  I switched to 
> graphical-session.target.
>
> I believe one issue remains.
>
> On login, after a reboot, the app is started.  And, on logout the app is 
> terminated.
>
> The issue is that if the user logs out and logs back in the service is not 
> run.
>
> How to make sure the service is run each time the user logs in?
>
>


Re: [systemd-devel] Xorg or Wayland Environment

2021-09-19 Thread Michael Biebl
Am So., 19. Sept. 2021 um 15:48 Uhr schrieb Ed Greshko :
>
> On 19/09/2021 21:39, Michael Biebl wrote:
>
> A useful command in this context is
>
> systemctl --user show-environment
>
>
> OK, that was helpful.  But leads to another question.
>
> How to run the service only if KDE_FULL_SESSION=true?

I have no idea what that is, sorry. I'm not really familiar with KDE/Plasma


Re: [systemd-devel] Xorg or Wayland Environment

2021-09-19 Thread Michael Biebl
A useful command in this context is

systemctl --user show-environment

Am So., 19. Sept. 2021 um 11:53 Uhr schrieb Mantas Mikulėnas
:
>
> On Sun, Sep 19, 2021 at 4:05 AM Ed Greshko  wrote:
>>
>> Not a everyday systemd service writer
>>
>> I've written a user service file to start an app on login.  It works well 
>> for Xorg with Environment=DISPLAY=:0.
>>
>> But I've found that under Wayland the DISPLAY=:1 after a logout of Xorg and 
>> login to a
>> Wayland session.
>>
>> What would be the proper way to get the DISPLAY environment varible use it 
>> as opposed
>> to "hard" coding it?
>
>
> The proper way is to have the desktop environment upload DISPLAY (and 
> whatever else is relevant, such as XAUTHORITY or WAYLAND_DISPLAY or 
> XDG_SESSION_TYPE) into systemd --user, so that it would be automatically 
> available to your service without doing anything special.
>
> For example, gnome-session does this for GNOME (it calls systemd's 
> UnsetAndSetEnvironment in gsm-util.c), and 
> /etc/X11/xinit/xinitrc.d/50-systemd-user.sh handles the bare minimum for 
> other Xorg-based desktops (when startx is used).
>
> If KDE integrates with systemd --user in any way (i.e. if it actually has a 
> "plasma-core.target" that you mention), I'd really expect it to do the same 
> before it tries to start its own targets, otherwise they would be kind of 
> useless.
>
> --
> Mantas Mikulėnas


Re: [systemd-devel] Xorg or Wayland Environment

2021-09-19 Thread Michael Biebl
You don't hard-code it, you just use it?

In your case, since you have a user service which appears bound to the
lifetime of a graphical (X/Wayland) session, I guess
graphical-session.target is what you want.
See man systemd.special.

So far, I think only GNOME implements graphical-session.target though.

Am So., 19. Sept. 2021 um 03:05 Uhr schrieb Ed Greshko :
>
> Not a everyday systemd service writer
>
> I've written a user service file to start an app on login.  It works well for 
> Xorg with Environment=DISPLAY=:0.
>
> But I've found that under Wayland the DISPLAY=:1 after a logout of Xorg and 
> login to a
> Wayland session.
>
> What would be the proper way to get the DISPLAY environment varible use it as 
> opposed
> to "hard" coding it?


Re: [systemd-devel] [hostnamed] Why the service will automatically exit after 30 seconds

2021-08-18 Thread Michael Biebl
Am Mi., 18. Aug. 2021 um 03:35 Uhr schrieb 李成刚 :
>
> How to configure this service so that it will not automatically exit

You can't. The exit-on-idle timeout of 30s is hard-coded.


Re: [systemd-devel] Antw: [EXT] Upgraded multiple systems to systemd 249.3 and all had eth1 not started / configured

2021-08-16 Thread Michael Biebl
How exactly do you rename your interfaces? Do you use a udev rule? Can
you post those scripts/rules?


Re: [systemd-devel] Resource ( systemd )

2021-07-14 Thread Michael Biebl
There is no such property in .service units.

What you might do is have .path unit which monitors your python script
and triggers a restart.service which restarts server.service


Am Mi., 14. Juli 2021 um 04:38 Uhr schrieb Webstrucs :
>
> I'm developing a web server in python that is referenced in the path inside a 
> systemd service ( server.service ). In the path that points to the execution 
> of the python file it works without problems but when I make any changes in 
> this file it is necessary to restart the file in order to get the updates. Is 
> there any way to implement a property in (server.service) of the type 
> (autosave) so that you no longer need to use restarting the service when 
> there are changes in the related file in python ?
>
> Att,
> João Aguiar
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


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

2021-06-01 Thread Michael Biebl
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?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] minimum required meson version bump?

2021-05-13 Thread Michael Biebl
Am Do., 13. Mai 2021 um 19:15 Uhr schrieb Zbigniew Jędrzejewski-Szmek
:
>
> Hi,
> we're considering bumping the meson version from the current 0.46 to
> something more recent (0.52 or 0.53…). Ubuntu Biionic 18.04 has 0.45, so
> it is below the cutoff point already. Focal 20.04 has 0.53.2.
> Would this be a problem for anyone?

Thanks for asking. No problem from the Debian PoV.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] early mounts in systemd

2021-05-01 Thread Michael Biebl
Am Sa., 1. Mai 2021 um 18:07 Uhr schrieb Michael Biebl :
>
> Am Sa., 1. Mai 2021 um 17:46 Uhr schrieb Dave Howorth 
> :
> > If systemd removes (i.e. doesn't obey) a directive, I'd expect it to be
> > polite and log that fact somewhere. No?
>
> It should, yes.

To be precise, it should log a message like here
https://sources.debian.org/src/systemd/247.3-5/src/core/transaction.c/?hl=414#L414
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] early mounts in systemd

2021-05-01 Thread Michael Biebl
Am Sa., 1. Mai 2021 um 17:46 Uhr schrieb Dave Howorth :
> If systemd removes (i.e. doesn't obey) a directive, I'd expect it to be
> polite and log that fact somewhere. No?

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


Re: [systemd-devel] early mounts in systemd

2021-05-01 Thread Michael Biebl
Am Sa., 1. Mai 2021 um 08:44 Uhr schrieb Luca Boccassi
:
>
> On Fri, 30 Apr 2021 at 22:15, Michael Biebl  wrote:
> >
> > I wonder if you have a dependency loop somewhere and systemd resolves
> > this by removing that ordering.
>
> As mentioned earlier, I strongly suspect systemd-tmpfiles-setup.service - I 
> had the same issue, because my /var/log partition is also not mounted in the 
> initramfs for $reasons, so it appears late at boot.
> I'd suggest again to try and override it.

I guess my point is, that before trying to suggest solutions, we
should understand what the underlying problem is first.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] early mounts in systemd

2021-04-30 Thread Michael Biebl
Am Fr., 30. Apr. 2021 um 20:27 Uhr schrieb Rick Winscot
:

> At this point, flush is attempting to re-route /run/log/journal to 
> /var/log/journal ... and the /var partition is not yet mounted. Units 
> generated for fstab in /run/systemd/generator that manage the mount have an 
> After=local-fs-pre.target which is too late.
>
> Other dependency errors appear in the log; all with the same root cause. By 
> the time [ a specified service ] that uses /var is ready, the partition has 
> not yet been mounted. My solution resolves the /var mount as soon as the 
> block device is seen by udev - which made all the dependency errors go away.

Fwiw, I can't reproduce the problem. systemd-journal-flush.service is
correctly started after /var has been mounted.
In case you are interested, I attached a journalctl dump, /etc/fstab
and systemd-analyze dump as well.
As you can see, systemd-journal-flush.service has a proper
After=var.mount ordering.

I wonder if you have a dependency loop somewhere and systemd resolves
this by removing that ordering.


fstab
Description: Binary data


journal.txt.gz
Description: application/gzip


systemd-analyze.dump.txt.gz
Description: application/gzip
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] early mounts in systemd

2021-04-30 Thread Michael Biebl
Am Fr., 30. Apr. 2021 um 19:42 Uhr schrieb Rick Winscot
:
>
> systemd 247

Ok, thanks

> /etc/systemd/journald.conf storage is persistent, 
> systemd-journal-flush.service has RequiresMountsFor=/var/log/journal.
>
> Mounting /var on a separate read-write partition handles the persistent log 
> requirement as well as offloading other read-write operations that can no 
> longer live on the rootfs... being read-only.

Sure, but what is the actual problem? I do have systems with a
separate /var and don't remember any ordering issues / race
conditions.
Do you have any error messages / journal logs which show the issue?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] early mounts in systemd

2021-04-30 Thread Michael Biebl
What is the actual problem you have with a separate /var and systemd-journald?
For completeness sake, which systemd version do you have?

Am Fr., 30. Apr. 2021 um 16:39 Uhr schrieb Rick Winscot
:
>
> We have an embedded product that uses a minimal Linux distribution generated 
> via Buildroot.
>
> Early in the project it was decided to make the rootfs read-only... in an 
> effort to improve durability in environments where power fluctuations might 
> cause problems on the eMMC. At the same time, making logging (e.g. /var) 
> persistent for debugging was added to requirements. Persistent storage would 
> be achieved by mounting /var to a separate partition that is read-write.
>
> Several-hundred hours later... with many systemd-analyze reports and various 
> configurations tested, we have determined that managing the /var mount with 
> stadard services is not going to work due to tightly coupled and precisely 
> timed dependencies. Attempts with /etc/fstab and the systemd generator are 
> also unstable.
>
> Getting /var mounted in proximity to the initialization of 
> systemd-journald.service seemed illusive.
>
> Several days ago I found a post on Stackoverflow that tied into udev triggers 
> that seemed promising; resulting in the method outlined below. Initial 
> testing shows proper timing with all dependencies satisfied. However, the 
> solution feels... hackey.
>
> My question for anyone on the list, is the method outlined below a reasonable 
> solution to mounting /var early in the start-up cycle?
>
> Or... is there a better way? Some trimming
>
>
> Step One: Create a systemd service that mounts /var to the specified partition
> Service:  /etc/systemd/system/var.service
>
> [Unit]
> Description=service for mounting /var
> DefaultDependencies=no
>
> [Service]
> Type=oneshot
> RemainAfterExit=yes
> ExecStart=/bin/mount /dev/mmcblk0p6
>
>
> Step Two: Add a nofail mount
> fstab:/etc/fstab
>
> /dev/root / auto rw 0 1
> /dev/mmcblk0p6 /var ext4 rw,nofail 0 0
>
>
> Step Three: Add a wants dependency on the mount in udev triggers (some lines 
> deleted for brevity)
> Service:/usr/lib/systemd/system/systemd-udev-trigger.service
>
> [Unit]
> ...
> Wants=systemd-udevd.service var.service
>
> [Service]
> ...
> ExecStart=udevadm trigger --type=subsystems --action=add ; /usr/bin/udevadm 
> trigger
>
>
> Finally, systemd-analyze plot shows that the mount works as desired.
>
> systemd-udev-trigger.service
> var.service
> dev-mmcblk0p6.device
> var.mount
> 
> systemd-remount-fs.service
> systemd-journal-flush.service
> local-fs-pre.target
> 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] bitcoind.service activation problem

2021-04-10 Thread Michael Biebl
I guess it's ok to ask such question on this mailing list, as it is
rather low traffic.

That said, more details are always better. So instead of a screenshot,
include a full copy of the service files and the full status and/or
journalctl -u bitcoind.service output.

This is either a configuration problem or the service file does not
have the proper Type=

Am Sa., 10. Apr. 2021 um 15:36 Uhr schrieb Tomasz Torcz :
>
> Dnia Sat, Apr 10, 2021 at 05:39:34PM +0600, Shafiun Miraz napisał(a):
> > [image: image.png]
> > [image: image.png]
> > I am getting this error. Please someone help me!
>
>   Hey Shafiun, couple of notes:
>
> - sending screenshots is not helpful, please just copy the message next
>   time;
>
> - there are no actual information why bitcoind.service is not starting.
>   Use "systemctl status bitcoind" to see more information and logs
>   related to the bitcoind.service. You can also use
>   "journalctl -u bitcoind.service" to see full logs.
>
>   I expect startup problem is connected to bitcoind's configuration, but
>   without logs it's only guesswork.
>
> - finally, this is not a correct place to get support. Please open a bug
>   with your Linux Distribution and ask them to replace systemd-devel URL
>   with real support address (bugzilla, forum, github issues etc.).
>   This way users will get quicker support in the future.
>
> --
> Tomasz TorczOnly gods can safely risk perfection,
> to...@pipebreaker.pl it's a dangerous thing for a man.  — Alia
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


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

2021-03-28 Thread Michael Biebl
Am So., 28. März 2021 um 21:19 Uhr schrieb lejeczek :
>   Main PID: 922 (code=exited, status=0/SUCCESS)

[..]

> Restart=on-failure

The service terminated with a zero exit code and you use Restart=on-failure.
A zero exit code is not treated as failure.
___
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-11 Thread Michael Biebl
Am Mo., 11. Jan. 2021 um 18:26 Uhr schrieb 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

So I guess no definite bug reports then. Ok.

> 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

Really?

Anyway, I appreciate your contribution regarding lto=, but let's
leave it at that.
___
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-11 Thread Michael Biebl
Am Mo., 11. Jan. 2021 um 18:10 Uhr 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.

That said, it would probably be sufficient if only parts of the
available runners enable lto and the rest doesn't.
___
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-11 Thread 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.
___
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-11 Thread 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.
___
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-11 Thread Michael Biebl
Am Mo., 11. Jan. 2021 um 16:12 Uhr schrieb Reindl Harald
:
> export LDFLAGS="-Wl,--as-needed -Wl,-z,now -Wl,-z,relro -pie %{optflags}
> -flto=%(nproc)"
> %meson

Thanks for the hint. I tried it, but it didn't really help.
___
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-11 Thread 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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] Is LTO worth it?

2021-01-11 Thread Michael Biebl
Hi,

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.
I also debdiffed the produced binary and LTO seems to produce bigger
binaries as well.
Most noticably (sizes in kB)
udev  9287 vs 8971
systemd 14755 vs 15998

LTO manages to strip some library dependencies here and there, but
that's about it.
Attached is a full debdiff output
$ debdiff no-lto/systemd_247.2-4_amd64.changes
lto/systemd_247.2-4_amd64.changes | colordiff
File lists identical (after any substitutions)

Control files of package libnss-myhostname: lines which differ (wdiff format)
-
Depends: libc6 (>= [-2.30), libselinux1 (>= 3.1~)-] {+2.30)+}
Installed-Size: [-265-] {+233+}

Control files of package libnss-mymachines: lines which differ (wdiff format)
-
Depends: libc6 (>= 2.30), [-libcap2 (>= 1:2.24-9~), libselinux1 (>=
3.1~),-] systemd-container (= 247.2-4)
Installed-Size: [-499-] {+419+}

Control files of package libnss-resolve: lines which differ (wdiff format)
--
Depends: libc6 (>= 2.30), [-libselinux1 (>= 3.1~),-] systemd (= 247.2-4)
Installed-Size: [-277-] {+237+}

Control files of package libnss-systemd: lines which differ (wdiff format)
--
Depends: libc6 (>= 2.30), [-libcrypt1 (>= 1:4.1.0), libselinux1 (>=
3.1~),-] systemd (= 247.2-4)
Installed-Size: [-417-] {+361+}

Control files of package libpam-systemd: lines which differ (wdiff format)
--
Depends: libc6 (>= 2.30), [-libcap2 (>= 1:2.24-9~), libcrypt1 (>=
1:4.1.0),-] libpam0g (>= 0.99.7.1), [-libselinux1 (>= 3.1~),-] systemd
(= 247.2-4), libpam-runtime (>= 1.0.1-6), dbus, systemd-sysv
Installed-Size: [-673-] {+573+}

No differences were encountered between the control files of package
libsystemd-dev

Control files of package libsystemd0: lines which differ (wdiff format)
---
Installed-Size: [-963-] {+863+}
Pre-Depends: libc6 (>= 2.30), [-libcap2 (>= 1:2.24-9~),-] libgcrypt20
(>= 1.8.0), liblz4-1 (>= 0.0~r122), liblzma5 (>= 5.1.1alpha+20120614),
[-libselinux1 (>= 3.1~),-] libzstd1 (>= 1.4.0)

No differences were encountered between the control files of package libudev-dev

Control files of package libudev1: lines which differ (wdiff format)

Depends: libc6 (>= [-2.30), libselinux1 (>= 3.1~)-] {+2.30)+}
Installed-Size: [-332-] {+280+}

Control files of package libudev1-udeb: lines which differ (wdiff format)
-
Installed-Size: [-213-] {+161+}

Control files of package systemd: lines which differ (wdiff format)
---
Depends: {+libacl1 (>= 2.2.23),+} libapparmor1 (>= 2.13), libaudit1
(>= 1:2.2.1), {+libcap2 (>= 1:2.24-9~),+} libcrypt1 (>= 1:4.4.0),
libcryptsetup12 (>= 2:2.3), libgnutls30 (>= 3.7.0), libgpg-error0 (>=
1.14), libip4tc2 (>= 1.8.3), libkmod2 (>= 5~), liblz4-1 (>= 0.0~r130),
{+libmount1 (>= 2.30),+} libpam0g (>= 0.99.7.1), libseccomp2 (>=
2.4.1), libsystemd0 (= 247.2-4), systemd-timesyncd | time-daemon,
util-linux (>= 2.27.1), mount (>= 2.26), adduser
Installed-Size: [-14755-] {+15998+}
Pre-Depends: [-libacl1 (>= 2.2.23),-] libblkid1 (>= 2.24), libc6 (>=
2.30), [-libcap2 (>= 1:2.24-9~),-] libgcrypt20 (>= 1.8.0), liblz4-1
(>= 0.0~r122), liblzma5 (>= 5.1.1alpha+20120614), [-libmount1 (>=
2.30),-] libselinux1 (>= 3.1~), libzstd1 (>= 1.4.0)

Control files of package systemd-container: lines which differ (wdiff format)
-
Installed-Size: [-1230-] {+1214+}

No differences were encountered between the control files of package
systemd-coredump

Control files of package systemd-journal-remote: lines which differ
(wdiff format)
--
Installed-Size: [-333-] {+329+}

No differences were encountered between the control files of package
systemd-sysv

Control files of package systemd-tests: lines which differ (wdiff format)
-
Depends: libacl1 (>= 2.2.23), libapparmor1 (>= 2.13), libaudit1 (>=
1:2.2.1), libblkid1 (>= 2.24), libc6 (>= 2.30), libcap2 (>=
1:2.24-9~), libdbus-1-3 (>= 1.9.14), libgcrypt20 (>= 1.8.0),
libglib2.0-0 (>= 2.26.0), libgpg-error0 (>= 1.14), {+libip4tc2 (>=
1.8.3),+} libkmod2 (>= 5~), liblz4-1 

Re: [systemd-devel] SystemD dependency problem

2020-12-22 Thread Michael Biebl
In addition to what Mantas said, I'd suggest reading man systemd.special.
and https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/

This should give you an idea what network-online.target is supposed to be.
It's not a target to hook arbitrary services into (via WantedBy).
Your service looks like multi-user.target is a better fit.

Stuff like NetworkManager-wait-online.service or
systemd-networkd-wait-online.service is something which should hook
into network-online.target via WantedBy.


Am Di., 22. Dez. 2020 um 14:17 Uhr schrieb Mantas Mikulėnas :
>
> On Tue, Dec 22, 2020 at 1:36 PM Ronald Wimmer  wrote:
>>
>> 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?
>
>
> 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.)
>
> However, Docker has "After=network-online.target", so you end up creating an 
> ordering loop:
>
> * yourthing.service has no After=, but it runs `docker` commands and cannot 
> finish until docker.service is up;
> * docker.service explicitly has After=network-online.target and won't start 
> until that target is reached;
> * but network-online.target has an implicit After=yourthing.service (as 
> explained above).
>
> --
> Mantas Mikulėnas
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


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

2020-11-23 Thread 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?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd prerelease 247-rc2

2020-11-13 Thread Michael Biebl
Am Do., 12. Nov. 2020 um 18:13 Uhr schrieb Zbigniew Jędrzejewski-Szmek
:

> The tags change is probably limited in effect, and the lack of handling
> of "bind" in rules will be more important. But, as you said, that change
> was already happening since kernel 4.2. So it's possible that the biggest
> effect is that with our announcement more people will notice that things
> are not working as expected. I think it's safe to push 247 to users, but
> be prepared for some bug reports.

Unfortunately I wasn't so lucky and my X session got killed during the
update from v246 to v247 (along with other services that had BindsTo=
afaics)

I've filed https://github.com/systemd/systemd/issues/17605 for now
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd prerelease 247-rc2

2020-11-12 Thread Michael Biebl
Hi there

Am Do., 12. Nov. 2020 um 11:58 Uhr schrieb systemd tag bot
:
>
> A new systemd ☠️ pre-release ☠️ has just been tagged. Please download the 
> tarball here:
>
> https://github.com/systemd/systemd/archive/v247-rc2.tar.gz

Congrats to the new release!

> Changes since the previous release:
>
> * KERNEL API INCOMPATIBILITY: Linux 4.12 introduced two new uevents
>   "bind" and "unbind" to the Linux device model. When this kernel
>   change was made, systemd-udevd was only minimally updated to handle
>   and propagate these new event types. The introduction of these new
>   uevents (which are typically generated for USB devices and devices
>   needing a firmware upload before being functional) resulted in a
>   number of issues which we so far didn't address. We hoped the kernel
>   maintainers would themselves address these issues in some form, but
>   that did not happen. To handle them properly, many (if not most) 
> udev
>   rules files shipped in various packages need updating, and so do 
> many
>   programs that monitor or enumerate devices with libudev or 
> sd-device,
>   or otherwise process uevents. Please note that this incompatibility
>   is not fault of systemd or udev, but caused by an incompatible 
> kernel
>   change that happened back in Linux 4.12, but is becoming more and
>   more visible as the new uevents are generated by more kernel 
> drivers.
>
>   To minimize issues resulting from this kernel change (but not avoid
>   them entirely) starting with systemd-udevd 247 the udev "tags"
>   concept (which is a concept for marking and filtering devices during
>   enumeration and monitoring) has been reworked: udev tags are now
>   "sticky", meaning that once a tag is assigned to a device it will 
> not
>   be removed from the device again until the device itself is removed
>   (i.e. unplugged). This makes sure that any application monitoring
>   devices that match a specific tag is guaranteed to both see uevents
>   where the device starts being relevant, and those where it stops
>   being relevant (the latter now regularly happening due to the new
>   "unbind" uevent type). The udev tags concept is hence now a concept
>   tied to a *device* instead of a device *event* — unlike for example
>   udev properties whose lifecycle (as before) is generally tied to a
>   device event, meaning that the previously determined properties are
>   forgotten whenever a new uevent is processed.
>
>   With the newly redefined udev tags concept, sometimes it's necessary
>   to determine which tags are the ones applied by the most recent
>   uevent/database update, in order to discern them from those
>   originating from earlier uevents/database updates of the same
>   device. To accommodate for this a new automatic property 
> CURRENT_TAGS
>   has been added that works similar to the existing TAGS property but
>   only lists tags set by the most recent uevent/database
>   update. Similarly, the libudev/sd-device API has been updated with
>   new functions to enumerate these 'current' tags, in addition to the
>   existing APIs that now enumerate the 'sticky' ones.
>
>   To properly handle "bind"/"unbind" on Linux 4.12 and newer it is
>   essential that all udev rules files and applications are updated to
>   handle the new events. Specifically:
>
>   • All rule files that currently use a header guard similar to
> ACTION!="add|change",GOTO="xyz_end" should be updated to use
> ACTION=="remove",GOTO="xyz_end" instead, so that the
> properties/tags they add are also applied whenever "bind" (or
> "unbind") is seen. (This is most important for all physical device
> types — those for which "bind" and "unbind" are currently
> generated, for all other device types this change is still
> recommended but not as important — but certainly prepares for
> future kernel uevent type additions).
>
>   • Similarly, all code monitoring devices that contains an 'if' 
> branch
> discerning the "add" + "change" uevent actions from all other
> uevents actions (i.e. considering devices only relevant after 
> "add"
> or "change", and irrelevant on all other events) should be 
> reworked
> to instead negatively check for "remove" only (i.e. considering
> devices relevant after all event types, except for "remove", which
> invalidates the device). Note that this also means that devices
> should be considered relevant on "unbind", even though 
> conceptually
> this — in some form — 

Re: [systemd-devel] ssh.service in rescue.target

2020-11-09 Thread Michael Biebl
Am Mo., 9. Nov. 2020 um 18:25 Uhr schrieb Michael Biebl :
> I guess this is kinda moot now, given that the initscripts package was
> completely removed in Ubuntu 20.10 it seems.
> Fwiw, I'd be surprised if there really are any packages in 20.04 still
> depending on initscripts.
> Maybe just purge the package (remove is not sufficient, initscripts
> being conffiles and all)

Hm, I guess Ubuntu has dropped the initscripts package for much longer already:

At least since bionic:

+sysvinit (2.88dsf-59.10ubuntu1) bionic; urgency=medium
+
+  * Merge with Debian, restoring 6ac609340af19a8d021c5ab8fea50c65241d1d0b:
+- When building for Ubuntu, skip all binaries except for sysvinit-utils.
+
+ -- Adam Conrad   Wed, 01 Nov 2017 15:00:29 -0600

So, Phillip, if you still have an initscripts package installed on
20.04, this is a left-over from previous dist-upgrades.

Purge the package (along with sysv-rc etc, in case you still have them
installed)

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


Re: [systemd-devel] ssh.service in rescue.target

2020-11-09 Thread Michael Biebl
Am Mo., 9. Nov. 2020 um 18:20 Uhr schrieb Michael Biebl :
>
> Am Mo., 9. Nov. 2020 um 17:12 Uhr schrieb Simon McVittie :
> >
> > On Mon, 09 Nov 2020 at 09:16:05 -0500, Phillip Susi wrote:
> > > I guess I'll try masking it.
> >
> > The Debian/Ubuntu package for systemd already masks various services
> > that are superseded by something in systemd, such as procps.service and
> > rcS.service. It used to also mask all the services from initscripts,
> > but that seems to have been dropped in version 243-5.
> >
> > systemd-sysv-generator (which generates systemd service units corresponding
> > to sysv-rc services) has stopped generating units for sysv-rc services that
> > run in rcS, rc0 and rc6, but still generates units for rc1 (mapped to
> > rescue.target). killprocs runs in rc1.
> >
> > Perhaps the systemd Debian/Ubuntu package still needs to mask rc1 services
> > like killprocs, or perhaps the initscripts package should take over
> > responsibility for masking rc1 services that it ships if they are not
> > applicable to systemd,
>
> https://tracker.debian.org/news/874168/accepted-sysvinit-288dsf-5910-source-into-unstable/
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874685
>
> Masking those SysV init specific services was moved to initscripts a
> long time ago (before I dropped those masks from the systemd package).
>
> Obviously I can't speak for the Ubuntu package

I guess this is kinda moot now, given that the initscripts package was
completely removed in Ubuntu 20.10 it seems.
Fwiw, I'd be surprised if there really are any packages in 20.04 still
depending on initscripts.
Maybe just purge the package (remove is not sufficient, initscripts
being conffiles and all)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] ssh.service in rescue.target

2020-11-09 Thread Michael Biebl
Am Mo., 9. Nov. 2020 um 17:12 Uhr schrieb Simon McVittie :
>
> On Mon, 09 Nov 2020 at 09:16:05 -0500, Phillip Susi wrote:
> > I guess I'll try masking it.
>
> The Debian/Ubuntu package for systemd already masks various services
> that are superseded by something in systemd, such as procps.service and
> rcS.service. It used to also mask all the services from initscripts,
> but that seems to have been dropped in version 243-5.
>
> systemd-sysv-generator (which generates systemd service units corresponding
> to sysv-rc services) has stopped generating units for sysv-rc services that
> run in rcS, rc0 and rc6, but still generates units for rc1 (mapped to
> rescue.target). killprocs runs in rc1.
>
> Perhaps the systemd Debian/Ubuntu package still needs to mask rc1 services
> like killprocs, or perhaps the initscripts package should take over
> responsibility for masking rc1 services that it ships if they are not
> applicable to systemd,

https://tracker.debian.org/news/874168/accepted-sysvinit-288dsf-5910-source-into-unstable/
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874685

Masking those SysV init specific services was moved to initscripts a
long time ago (before I dropped those masks from the systemd package).

Obviously I can't speak for the Ubuntu package
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] ssh.service in rescue.target

2020-11-06 Thread Michael Biebl
Am Fr., 6. Nov. 2020 um 22:31 Uhr schrieb Phillip Susi :
>
>
> Lennart Poettering writes:
>
> > Are you running systemd? If so, please get rid of "killproc". It will
> > interfere with systemd's service management.
>
> I see.. apparently Ubuntu still has it around.

Are you sure?
Which Ubuntu version is that?
At least in Debian, /etc/init.d/killprocs is shipped by "initscripts"
which is no longer installed by default.
___
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-19 Thread Michael Biebl
Am Mo., 19. Okt. 2020 um 15:56 Uhr schrieb Lennart Poettering
:
>
> >   2) Could resolved be changed so that this message is only emitted
> > (say) once for every 100 or 500 times that the condition is
> > detected.
>
> We actually try hard to suppress unnecessary log lines, but I think
> this one is a downstream change.
>


https://git.launchpad.net/ubuntu/+source/systemd/tree/debian/patches/resolved-Mitigate-DVE-2018-0001-by-retrying-NXDOMAIN-with.patch?h=ubuntu/focal-updates

Bringing Dimitri into the loop here.

Michael
___
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-21 Thread Michael Biebl
Hm, some performance penalty is certainly expected but 350times slower
looks like something is odd.
Would be interesting to know, if you can reproduce the performance
issue with a more recent version.
Afaik, using imuxsock and syslog forwarding should be more performant
then imjournal (which was suggested earlier).

You could configure systemd, to not do syslog forwarding and let
rsyslog handle syslog messages directly.
This has a few downsides though:
- syslog messages don't end up in the journal
- non-syslog messages from journald don't end up in your syslog, say
messages from systemd or services logging to stdout/stderr.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Enable sandboxing options globally for all services

2020-09-09 Thread Michael Biebl
Am Mi., 9. Sept. 2020 um 21:40 Uhr schrieb Christopher Wong
:
>
> Hi,
>
>
> Is there a way to turn on a sandboxing option for all services?

Recent versions of systemd allow to use global drop-in config
snippets. See the changelog of v244

* Unit files now support top level dropin directories of the form
  .d/ (e.g. service.d/) that may be used to add configuration
  that affects all corresponding unit files.
___
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 Michael Biebl
Am So., 23. Aug. 2020 um 19:20 Uhr schrieb Tom Browder :

> I assume the data are correct, and I'm pretty sure there is some
> fancy, automated sysstemctl way to get it all working.  I would
> greatly appreciate some guidance as to how to install the files
> correctly.

Those files are installed correctly. What's your specific question?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Antw: [EXT] I/O error on "systemctl kill -s HUP rsyslog.service"

2020-08-13 Thread Michael Biebl
Am Do., 13. Aug. 2020 um 09:05 Uhr schrieb Andrei Borzenkov
:
>
> 13.08.2020 09:54, Harald Dunkel пишет:
> > On 8/12/20 2:16 PM, Andrei Borzenkov wrote:
> >> 12.08.2020 14:03, Harald Dunkel пишет:
> >>> See attachment. Hope this helps
> >>> Harri
> >>
> >>
> >>> 1 openat(AT_FDCWD,
> >>> "/sys/fs/cgroup/unified/system.slice/rsyslog.service/cgroup.procs",
> >>> O_RDONLY|O_CLOEXEC) = 24
> >>> 1 read(24, "0\n1544456\n", 4096)= 10
> >>
> >>
> >> kernel returns "0" as process number in this cgroup which results in EIO
> >> returned by systemd.
> >
>
> systemd should really clearly log this (invalid PID and and in which
> cgroup it was). Returning generic error message without any indication
> what caused this error is not useful at all.

I agree. Could you file a github issue for this?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] : How to modify systemd so that the NTP function is disabled when systemd is first started?

2020-04-25 Thread Michael Biebl
Am Sa., 25. Apr. 2020 um 08:52 Uhr schrieb www :

> Apr 02 17:24:52 demoboard systemd[1]: System time before build time, 
> advancing clock.

See https://github.com/systemd/systemd/blob/master/src/core/main.c#L1485
or more specifically
https://github.com/systemd/systemd/blob/master/src/shared/clock-util.c#L145

If you want to change time_epoch, use the meson "time_epoch" build option.
time_epoch is currently derived frome the date, when the NEWS file was
last modified.
But you could set that to say 1.1.1970.


> Apr 02 17:25:02 demoboard systemd[1]: logrotate.timer: Not using persistent 
> file timestamp Sat 2020-04-25 13:45:26 CST as it is in the future.
> Apr 02 17:25:04 demoboard systemd[1]: Reached target Timers.
> Apr 02 17:25:38 demoboard systemd[1]: Starting Time & Date Service...
> Apr 02 17:25:40 demoboard systemd[1308]: systemd-timedated.service: 
> ProtectHostname=yes is configured, but the kernel does not support UTS 
> namespaces, ignoring namespace setup.
> Apr 02 17:25:42 demoboard systemd[1]: Started Time & Date Service.
> Apr 02 17:26:13 demoboard systemd[1]: systemd-timedated.service: Succeeded.
> Apr 02 17:27:03 demoboard systemd[1]: Starting Time & Date Service...
> Apr 02 17:27:03 demoboard systemd[1823]: systemd-timedated.service: 
> ProtectHostname=yes is configured, but the kernel does not support UTS 
> namespaces, ignoring namespace setup.
> Apr 02 17:27:03 demoboard systemd[1]: Started Time & Date Service.
>
> It can be seen from the log that after the TimeSync service is disabled, the 
> latest time is obtained from NTP server, but it is not updated to the system. 
> But the system time has also been modified.

systemd-timedated.service has nothing to do with NTP.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] user service conflict and confusion

2020-04-10 Thread Michael Biebl
Am Fr., 10. Apr. 2020 um 17:59 Uhr schrieb Matt Zagrabelny :
>
> Greetings,
>
> I am hitting a confusing scenario with my system. I am running 245.4-2 
> (Debian).
>
> I have a user service, mpd, which is failing to start. It is enabled:
>
> $ systemctl --user is-enabled mpd
> enabled
>
> And now that I look for the enabled unit within the filesystem, I don't see 
> it.
>
> I'm expecting to see something in ~/.config/systemd, but that directory 
> doesn't exist.

I suspect it is enabled system wide, i.e. in /etc/systemd/user
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] dockerd broken docker works without It own docker image but need

2020-03-26 Thread Michael Biebl
Am Do., 26. März 2020 um 21:43 Uhr schrieb Dorian ROSSE
:
>
> Do you know the dockerd mailing list?

Don't be lazy and find that out yourself. Google (or your search
engine of choice) is your friend.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Antw: [EXT] Infinite loop at startup on var fsck failure

2020-02-26 Thread Michael Biebl
Am Mi., 26. Feb. 2020 um 10:13 Uhr schrieb Ulrich Windl
:
>
> >>> Vito Caputo  schrieb am 25.02.2020 um 01:01 in
> Nachricht
> <7343_1582589314_5e546582_7343_4690_1_20200225000143.nowls5peec5sx...@shells.gnu
>
> eneration.com>:
> > Hello list,
> >
> > Today I experienced an unclean shutdown due to battery dying unexpectedly,
> > and it left my /var in a state requiring a manual fsck to repair errors.
>
> I wonder: Shouldn't be a fsck just be a journal reply these days? For ext >=3
> this should be quite fast. ReiserFS was rather slow several years ago (it did
> replay too much IMHO), but haven't used it the last five years.
>
> >
> > The normal startup process failed and dropped me to a rescue shell after
> > asking for my root password.  But I was unable to immediately run fsck
> > manually, because systemd was endlessly trying to fsck /var.
>
> That's not a problem of fsck.


I suspect that the real problem is, that fsck failed to fix the file
system, so as a result, systemd tried repeatedly to start the fsck job
for /var as var.mount was pulled in as a dependency (e.g. for
journald).
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Antw: Re: show journalctl while stopping?

2020-01-24 Thread Michael Biebl
Am Fr., 24. Jan. 2020 um 09:45 Uhr schrieb Ulrich Windl
:

> Similarly: Before bashing the proposal, why not think about an option that
> will enable that feature? Like "--verbose", "--monitor",
> "--whatever-you-like"...

There you go
https://github.com/systemd/systemd/blob/master/TODO#L891
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Hotplug auto mounting and masked mount units

2020-01-12 Thread Michael Biebl
Am Fr., 10. Jan. 2020 um 17:13 Uhr schrieb Phillip Susi :
>
>
> Lennart Poettering writes:
>
> > Can you file a bug about this? Sounds like something to fix.
>
> Sure.


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


Re: [systemd-devel] Antw: Re: Binary changed since start

2019-12-10 Thread Michael Biebl
There is a tool called needrestart which should do exactly what you want.
See
https://tracker.debian.org/pkg/needrestart
https://github.com/liske/needrestart

Am Di., 10. Dez. 2019 um 15:12 Uhr schrieb Ulrich Windl
:
>
> >>> Lennart Poettering  schrieb am 10.12.2019 um 12:32
> in
> Nachricht <20191210113234.GA16721@gardel-login>:
> > On Di, 10.12.19 10:38, Ulrich Windl (ulrich.wi...@rz.uni‑regensburg.de)
> wrote:
> >
> >> Hi!
> >>
> >> Two questions (In Linux it's possible to replace the image of the binary
> > that is executed on disk):
> >>
> >> 1) It seems my version of systemd (228) does not detect that a
> >> binary has changed since the service was started. In case it's still
> >> true in the current version, is it difficult to indicate that fact
> >> in "systemctl status .."?
> >
> > We don't, no. It has been requested before that we deal with that, but
> > it's not realistic to do this correctly. Thing is, binaries are
>
> Well at least "zypper ps" does that kind of things:
> # zypper ps
> The following running processes use deleted files:
>
> PID   | PPID  | UID  | User   | Command| Service| Files
> --+---+--++++--
> 2502  | 1 | 0| root   | multipathd | multipathd |
> /lib64/libtinfo.so.5.9
> 2903  | 1 | 100  | messagebus | dbus-daemon| dbus   |
> /lib64/libnss_sss.so.2
> 2967  | 1 | 0| root   | mcelog | mcelog |
> /lib64/libnss_sss.so.2
> 3774  | 1 | 0| root   | xinetd | xinetd |
> /lib64/libnss_sss.so.2
> 3796  | 1 | 1086 | nagios | nrpe   | nrpe   |
> /lib64/libnss_sss.so.2
> 3973  | 1 | 0| root   | sshd   | sshd   |
> /lib64/libnss_sss.so.2
> 4060  | 1 | 0| root   | automount  | autofs |
> /usr/lib64/libxml2.so.2.9.4
> 4074  | 1 | 0| root   | snmpd  | snmpd  |
> /lib64/libnss_sss.so.2
> 4079  | 1 | 74   | ntp| ntpd   | ntpd   |
> /lib64/libnss_sss.so.2
> 4080  | 4079  | 74   | ntp| ntpd   | ntpd   |
> /lib64/libnss_sss.so.2
> 4082  | 1 | 25   | at | atd| atd|
> /lib64/libnss_sss.so.2
> 4166  | 1 | 0| root   | bash   | md-mon |
> /lib64/libtinfo.so.5.9
> ...
> 25512 | 1 | 0| root   | cupsd  | cups   |
> /lib64/libnss_sss.so.2
> 26053 | 3973  | 0| root   | sshd   ||
> /lib64/libnss_sss.so.2
> 26061 | 26053 | 0| root   | bash   ||
> /lib64/libnss_sss.so.2
>
> # zypper ps -s
> The following running processes use deleted files:
>
> PID   | PPID  | UID  | User   | Command| Service
> --+---+--+++---
> 2502  | 1 | 0| root   | multipathd | multipathd
> 2903  | 1 | 100  | messagebus | dbus-daemon| dbus
> 2967  | 1 | 0| root   | mcelog | mcelog
> 3774  | 1 | 0| root   | xinetd | xinetd
> 3796  | 1 | 1086 | nagios | nrpe   | nrpe
> 3973  | 1 | 0| root   | sshd   | sshd
> 4060  | 1 | 0| root   | automount  | autofs
> 4074  | 1 | 0| root   | snmpd  | snmpd
> ...
>
> > generally not statically compiled, they link against other libraries
> > which might also be updated, and which would have to be checked
> > too. And they do so via module loading (i.e. dlopen()) and explicitly,
> > we'd have to check both, which already is harder, since you cannot
> > just look at the ELF headers of binaries to determine deps
> > anymore. But they also keep other resources mapped, for example l10n
> > and i18n data, and a lot of other stuff. We'd have to check that
> > too. And then, there are the invisible dependencies too: some file
> > changed that some library a program opens and reads, but only
> > sometimes: how would you ever figure out you need to restart the
> > service? And then, there's also the fact that C is just one
> > programming language and others work very differently, and require
> > other schemes for updating, i.e. Python does something very very
> > different.
> >
> > So in the end: implementing something like that could at best be a
> > heuristic, that works sometimes but not generally. I know that some
> > distros implemented a checker for this in their package manager. But I
> > am very sure this has no place in systemd, since it's black magic and
> > you never could rely on the correctness for that.
> >
> >> 2) Given 1), would it make sense to allow an option like
> >> "RestartIfBinary Changed"?
> >
> > Binding control flow to such a heuristic sounds even more dangerous to
> > me.
>
> I was asking for an option, not for a default.
>
> Regards,
> Ulrich
>
>
> >
> > Lennart
> >
> > ‑‑
> > Lennart 

Re: [systemd-devel] need help with undestanding a udev warning

2019-11-16 Thread Michael Biebl
Am Sa., 16. Nov. 2019 um 09:20 Uhr schrieb Andrei Borzenkov
:
>
> Likely result of mass-rewrite in
>
> commit 25de7aa7b90c23d33ea50ada1e50c5834a414237
> Author: Yu Watanabe 
> Date:   Thu Apr 25 01:21:11 2019 +0200
>
> udev: modernize udev-rules.c


A bug then? Or is there an error in the udev rule that I don't see?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] need help with undestanding a udev warning

2019-11-13 Thread Michael Biebl
Hi,

with v243 I get the following warning in my journal:

Nov 13 15:38:12 pluto systemd-udevd[319]:
/lib/udev/rules.d/90-libgpod.rules:19 IMPORT key takes '==' or '!='
operator, assuming '==', but please fix it.
Nov 13 15:38:12 pluto systemd-udevd[319]:
/lib/udev/rules.d/90-libgpod.rules:23 IMPORT key takes '==' or '!='
operator, assuming '==', but please fix it.

Looking at the rules file, it shows

ACTION=="add|change", ENV{USBMUX_SUPPORTED}=="1",
IMPORT{program}+="/lib/udev/iphone-set-info", GOTO="libgpod_end"
..
ACTION=="add|change", SUBSYSTEM=="usb", ATTR{idVendor}=="05ac",
ATTR{idProduct}=="129[0-9a]",
IMPORT{program}+="/lib/udev/iphone-set-info"

I don't see the error in those udev rules, so I was wondering why udev
is complaining about them
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] perform fsck on everyt boot

2019-11-11 Thread Michael Biebl
Am Mo., 11. Nov. 2019 um 16:47 Uhr schrieb Lennart Poettering
:
> Well, note that ext4's fsck only does an actual file system check
> every now and then.

Afair this is outdated knowledge. newer e2fsprogs versions no longer
setup ext4 file systems to do regular fscks.
At least on Debian sid, /etc/mke2fs.conf contains

enable_periodic_fsck = 0

Regards,
Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemctl stuck when run restart

2019-10-05 Thread Michael Biebl
Am Sa., 5. Okt. 2019 um 17:06 Uhr schrieb Hongyi Zhao :
> Type=notify

> $ sudo systemctl start ssh
> ^C
> werner@localhost:~/software/openssh$ sudo systemctl restart ssh
> ^C
>
> If I don't hit ^C, the command will stuck there for ever.

I don't think the upstream openssh supports sd_notify.
E.g in Debian it's a custom patch
https://salsa.debian.org/ssh-team/openssh/blob/master/debian/patches/systemd-readiness.patch

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] startup hang at 'load/save random seed'

2019-08-07 Thread Michael Biebl
See https://github.com/systemd/systemd/issues/13252

Am Mi., 7. Aug. 2019 um 00:39 Uhr schrieb Chris Murphy
:
>
> [   10.281769] fmac.local systemd[1]: Starting Update UTMP about
> System Boot/Shutdown...
> [   10.295504] fmac.local audit[806]: SYSTEM_BOOT pid=806 uid=0
> auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='
> comm="systemd-update-utmp" exe="/usr/lib/systemd/systemd-update-utmp"
> hostname=? addr=? terminal=? res=success'
> [   10.305289] fmac.local systemd[1]: Started Update UTMP about System
> Boot/Shutdown.
> [   10.305527] fmac.local audit[1]: SERVICE_START pid=1 uid=0
> auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
> msg='unit=systemd-update-utmp comm="systemd"
> exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=?
> res=success'
> [   15.264423] fmac.local systemd[1]: systemd-rfkill.service: Succeeded.
> [   15.268231] fmac.local audit[1]: SERVICE_STOP pid=1 uid=0
> auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
> msg='unit=systemd-rfkill comm="systemd" exe="/usr/lib/systemd/systemd"
> hostname=? addr=? terminal=? res=success'
> [  286.296649] fmac.local kernel: random: crng init done
> [  286.301223] fmac.local kernel: random: 7 urandom warning(s) missed
> due to ratelimiting
> [  286.319857] fmac.local systemd[1]: Started Load/Save Random Seed.
> [  286.322850] fmac.local audit[1]: SERVICE_START pid=1 uid=0
> auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
> msg='unit=systemd-random-seed comm="systemd"
> exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=?
> res=success'
> [  286.323576] fmac.local systemd[1]: Reached target System Initialization.
>
>
> I don't know why there's ratelimiting on urandom warnings, I have
> printk.devkmsg=on
>
> This also seems relevant.
>
> [chris@fmac ~]$ sudo journalctl -b -o short-monotonic | grep -i seed
> [8.870985] fmac.local systemd[1]: Starting Load/Save Random Seed...
> [9.021818] fmac.local systemd-random-seed[619]: Kernel entropy
> pool is not initialized yet, waiting until it is.
> [  286.319857] fmac.local systemd[1]: Started Load/Save Random Seed.
> [  286.322850] fmac.local audit[1]: SERVICE_START pid=1 uid=0
> auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
> msg='unit=systemd-random-seed comm="systemd"
> exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=?
> res=success'
> [chris@fmac ~]$
>
>
> ---
> Chris Murphy
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] lto issues

2019-08-06 Thread Michael Biebl
Am Di., 6. Aug. 2019 um 09:26 Uhr schrieb Zbigniew Jędrzejewski-Szmek
:
>
> On Sat, Aug 03, 2019 at 07:03:47PM +0200, Michael Biebl wrote:
> > Hi,
> >
> > today I tried compiling systemd v242 (on Debian sid) once using lto
> > (-Db_lto=true) and once without lto (-Db_lto=false).
> >
> > The lto build took approximately twice as long on my laptop (using
> > dpkg-buildpackage, which introduces a bit of overhead):
> >
> > lto:
> > real 11m22,605s
> > user 37m9,675s
> > sys 2m51,041s
> >
> > nolto:
> > real 6m35,615s
> > user 18m51,782s
> > sys 2m12,934s
> >
> > That's kinda expected. What suprised me though is that using lto
> > produced larger binaries:
>
> I built systemd in F31 (-Doptimization=2 -Db_lto=true/false, and I saw
> a big increase in binary sizes *before stripping*. After stripping,
> binaries with lto=true are smaller:
>
> $ ls -l build-rawhide{,-lto}/{systemd,src/shared/libsystemd-shared-243.so}
>   7116384 Aug  6 09:08 build-rawhide/systemd*
>  11951256 Aug  6 09:07 build-rawhide/src/shared/libsystemd-shared-243.so*
>   1594912 Aug  6 09:12 build-rawhide-lto/systemd*
>   3167096 Aug  6 09:11 build-rawhide-lto/src/shared/libsystemd-shared-243.so*
> $ strip build-rawhide{,-lto}/{systemd,src/shared/libsystemd-shared-243.so}
> $ ls -l build-rawhide{,-lto}/{systemd,src/shared/libsystemd-shared-243.so}
>   1439640 Aug  6 09:19 build-rawhide/systemd*
>   2806456 Aug  6 09:19 build-rawhide/src/shared/libsystemd-shared-243.so*
>   1370008 Aug  6 09:19 build-rawhide-lto/systemd*
>   2806288 Aug  6 09:19 build-rawhide-lto/src/shared/libsystemd-shared-243.so*


The sizes I posted i.e. the debdiff is after stripping.

gcc --version
gcc (Debian 8.3.0-19) 8.3.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

ld --version
GNU ld (GNU Binutils for Debian) 2.32.51.20190727
Copyright (C) 2019 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.

So with the toolchain I have, mostly has downsides. The only benefit
it seems to have is that it optimizes unnecessary library dependencies
away (see how the udev subpackage does not depend on libcap2 (>=
1:2.10), libidn2-0 (>= 0.6)



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] lto issues

2019-08-03 Thread Michael Biebl
Hi,

today I tried compiling systemd v242 (on Debian sid) once using lto
(-Db_lto=true) and once without lto (-Db_lto=false).

The lto build took approximately twice as long on my laptop (using
dpkg-buildpackage, which introduces a bit of overhead):

lto:
real 11m22,605s
user 37m9,675s
sys 2m51,041s

nolto:
real 6m35,615s
user 18m51,782s
sys 2m12,934s

That's kinda expected. What suprised me though is that using lto
produced larger binaries:

File lists identical (after any substitutions)

Control files of package libnss-myhostname: lines which differ (wdiff format)
-
Installed-Size: [-202-] {+222+}

Control files of package libnss-mymachines: lines which differ (wdiff format)
-
Depends: libc6 (>= 2.28), {+libcap2 (>= 1:2.10),+} systemd-container (= 242-2)
Installed-Size: [-401-] {+461+}

Control files of package libnss-resolve: lines which differ (wdiff format)
--
Depends: libc6 (>= 2.28), {+libcap2 (>= 1:2.10),+} systemd (= 242-2)
Installed-Size: [-396-] {+460+}

Control files of package libnss-systemd: lines which differ (wdiff format)
--
Depends: libc6 (>= 2.28), {+libcap2 (>= 1:2.10),+} systemd (= 242-2)
Installed-Size: [-400-] {+460+}

Control files of package libpam-systemd: lines which differ (wdiff format)
--
Depends: libc6 (>= 2.28), {+libcap2 (>= 1:2.10),+} libpam0g (>=
0.99.7.1), systemd (= 242-2), libpam-runtime (>= 1.0.1-6), dbus,
systemd-sysv
Installed-Size: [-398-] {+466+}

No differences were encountered between the control files of package
libsystemd-dev

Control files of package libsystemd0: lines which differ (wdiff format)
---
Installed-Size: [-774-] {+862+}
Pre-Depends: libc6 (>= 2.28), {+libcap2 (>= 1:2.10),+} libgcrypt20 (>=
1.8.0), liblz4-1 (>= 0.0~r122), liblzma5 (>= [-5.1.1alpha+20120614)-]
{+5.1.1alpha+20120614), libselinux1 (>= 2.1.9)+}

No differences were encountered between the control files of package libudev-dev

Control files of package libudev1: lines which differ (wdiff format)

Installed-Size: [-257-] {+297+}

Control files of package systemd: lines which differ (wdiff format)
---
Depends: [-libacl1 (>= 2.2.23),-] libapparmor1 (>= 2.9.0-3+exp2),
libaudit1 (>= 1:2.2.1), [-libcap2 (>= 1:2.10),-] libcryptsetup12 (>=
2:1.6.0), libgnutls30 (>= 3.6.6), libgpg-error0 (>= 1.14), libidn2-0
(>= 2.0.0), libip4tc2 (>= 1.8.3), libkmod2 (>= 5~), liblz4-1 (>=
0.0~r130), libmount1 (>= 2.30), libpam0g (>= 0.99.7.1), libpcre2-8-0
(>= 10.32), libseccomp2 (>= 2.3.1), libsystemd0 (= 242-2), util-linux
(>= 2.27.1), mount (>= 2.26), adduser
Installed-Size: [-13781-] {+12696+}
Pre-Depends: {+libacl1 (>= 2.2.23),+} libblkid1 (>= 2.24), libc6 (>=
2.28), {+libcap2 (>= 1:2.10),+} libgcrypt20 (>= 1.8.0), liblz4-1 (>=
0.0~r122), liblzma5 (>= 5.1.1alpha+20120614), libselinux1 (>= 2.1.9)

Control files of package systemd-container: lines which differ (wdiff format)
-
Installed-Size: [-1118-] {+1126+}

No differences were encountered between the control files of package
systemd-coredump

Control files of package systemd-journal-remote: lines which differ
(wdiff format)
--
Installed-Size: [-314-] {+318+}

No differences were encountered between the control files of package
systemd-sysv

Control files of package systemd-tests: lines which differ (wdiff format)
-
Depends: libacl1 (>= 2.2.23), libapparmor1 (>= 2.9.0-3+exp2),
libaudit1 (>= 1:2.2.1), libblkid1 (>= 2.24), libc6 (>= 2.28), libcap2
(>= 1:2.10), libcryptsetup12 (>= 2:1.6.0), libdbus-1-3 (>= 1.9.14),
libgcrypt20 (>= 1.8.0), libglib2.0-0 (>= 2.26.0), libgpg-error0 (>=
1.14), [-libidn2-0 (>= 2.0.0), libip4tc2 (>= 1.8.3),-] libkmod2 (>=
5~), liblz4-1 (>= 0.0~r130), libmount1 (>= 2.30), libpam0g (>=
0.99.7.1), libseccomp2 (>= 2.3.1), libselinux1 (>= 2.1.9), libsystemd0
(= 242-2), libudev1 (>= 215), systemd (= 242-2), zlib1g (>= 1:1.1.4),
python3
Installed-Size: [-26530-] {+24446+}

Control files of package udev: lines which differ (wdiff format)

Depends: libacl1 (>= 2.2.23), libblkid1 (>= 2.24), libc6 (>= 2.28),
{+libcap2 (>= 1:2.10), libidn2-0 (>= 0.6),+} libkmod2 (>= 5~),
libselinux1 (>= 2.1.9), adduser, dpkg (>= 1.19.3) | systemd-sysv,
libudev1 (= 242-2), util-linux (>= 2.27.1)
Installed-Size: 

Re: [systemd-devel] systemd-devel listed as support confuses users (was: connection failure)

2019-07-02 Thread Michael Biebl
Am Di., 2. Juli 2019 um 18:52 Uhr schrieb František Šumšal
:
> This, or since the URL leads to [0], it would be also useful to extend
> the "About systemd-devel" section to provide some kind of warning that
> this ML is mainly/only for upstream systemd, not for systemd shipped by
> distributions.

Fwiw, I have no problems if systemd related questions that also touch
distro specific issues are discussed here.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-devel listed as support confuses users (was: connection failure)

2019-07-02 Thread Michael Biebl
Am Di., 2. Juli 2019 um 16:16 Uhr schrieb Paul Menzel
:
> Reading the output above, I can see, why the people contact this mailing
> list.

I agree here. While we do have `support-url` which distros can
override, Apparently not all of them do.
We could probably change our build system, that `support-url` needs to
be set explicitly and if unset, no Support URL is printed in the
journal output.
Just an idea...


Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Antw: Re: Q: Implementing logrotate's postrotate with systemd

2019-06-11 Thread Michael Biebl
Am Di., 11. Juni 2019 um 16:18 Uhr schrieb Reindl Harald
:
>
>
>
> Am 11.06.19 um 15:00 schrieb Ulrich Windl:
>  Reindl Harald  schrieb am 11.06.2019 um 14:30 in
> > Nachricht <917331d8-845f-54d5-908c-e6c7d124a...@thelounge.net>:
> >>
> >> Am 11.06.19 um 13:34 schrieb Ulrich Windl:
> >>> I have a forking service (with a PID file) that can reopen the logfile 
> >>> after
> >> receiving SIGHUP. In the past I had implemented "rc{service} rotate" to 
> >> send
> >> SIGHUP to the daemon as "postrotate" action. After converting (actually 
> >> being
> >> converted ;-)) to systemd I dropped the LSB script, and wonder which 
> >> command
> >> to use as "postrotate" action:
> >>>
> >>> Should I implement a oneshot service (using "systemctl start {service}")
> >> that does depend on the actual service and send a SIGHUP on start, or is
> >> there a more elegent solution?
> >>
> >> that's what reload is all about
> >>
> >> [harry@srv-rhsoft:/etc/systemd/system]$ cat named.service | grep Reload
> >> ExecReload=/usr/bin/kill -HUP $MAINPID
> >
> > The manual page says it's about "configuration reload". I was talking about 
> > logfile rotation (my service does not suport configuration reload (other 
> > than restart))
>
> frankly it's nothing new or uncommon that services close and re-open
> their logfiles by "reload" and that's really not systemd specific,
> sysvinit had reload too
>
> it's you turn what happens with "systemctl reload yourservice" becaus
> ethere is no default action for that unless "ExecReload" is specified

Of course you can do whatever you please in ExecReload, but as said I
think it's good practice if "reload" has a certain consistent meaning
across services so admins not familiar with a particular service know
what to expect from "systemctl reload".

See also
https://github.com/rsyslog/rsyslog/commit/fd26a42bdc04eaf497cafd9ef806a54f3de1a7e9#diff-c64e6ed7f40ecd1530e093a77c9465f6



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Antw: Re: Q: Implementing logrotate's postrotate with systemd

2019-06-11 Thread Michael Biebl
Am Di., 11. Juni 2019 um 15:00 Uhr schrieb Ulrich Windl
:
>
> >>> Reindl Harald  schrieb am 11.06.2019 um 14:30 in
> Nachricht <917331d8-845f-54d5-908c-e6c7d124a...@thelounge.net>:
>
> >
> > Am 11.06.19 um 13:34 schrieb Ulrich Windl:
> >> I have a forking service (with a PID file) that can reopen the logfile 
> >> after
> > receiving SIGHUP. In the past I had implemented "rc{service} rotate" to send
> > SIGHUP to the daemon as "postrotate" action. After converting (actually 
> > being
> > converted ;-)) to systemd I dropped the LSB script, and wonder which command
> > to use as "postrotate" action:
> >>
> >> Should I implement a oneshot service (using "systemctl start {service}")
> > that does depend on the actual service and send a SIGHUP on start, or is
> > there a more elegent solution?
> >
> > that's what reload is all about
> >
> > [harry@srv-rhsoft:/etc/systemd/system]$ cat named.service | grep Reload
> > ExecReload=/usr/bin/kill -HUP $MAINPID
>
> The manual page says it's about "configuration reload". I was talking about 
> logfile rotation (my service does not suport configuration reload (other than 
> restart)).

Right, I wouldn't use ExecReload= for this use case myself.
If I run "systemctl reload $service", I expect that the service
reloads its configuration and I think it's good practice to be
consistent in that matter and not overload ExecReload= with "rotate
log files".


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Q: Implementing logrotate's postrotate with systemd

2019-06-11 Thread Michael Biebl
A separate oneshot service sounds like overkill. I would probably use
something like
`systemctl kill -s HUP ${service}.service`
If your sevices spawns multiple processes and you only want to send
SIGHUP to the main process, you should add a `--kill-who=main`

All documented nicely in
https://www.freedesktop.org/software/systemd/man/systemctl.html

Am Di., 11. Juni 2019 um 13:34 Uhr schrieb Ulrich Windl
:
>
> Hi!
>
> I have a forking service (with a PID file) that can reopen the logfile after 
> receiving SIGHUP. In the past I had implemented "rc{service} rotate" to send 
> SIGHUP to the daemon as "postrotate" action. After converting (actually being 
> converted ;-)) to systemd I dropped the LSB script, and wonder which command 
> to use as "postrotate" action:
>
> Should I implement a oneshot service (using "systemctl start {service}") that 
> does depend on the actual service and send a SIGHUP on start, or is there a 
> more elegent solution?
>
> Regards,
> Ulrich
>
>
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Wtrlt: Antw: Re: Can I enable/disable a target?

2019-05-09 Thread Michael Biebl
Am Do., 9. Mai 2019 um 15:52 Uhr schrieb Ulrich Windl
:
>
> (Sorry, I didn't send to the list before)
> >>> Ulrich Windl  schrieb am 09.05.2019 um 
> >>> 14:28
> in Nachricht <5cd44cae.ed38.00a...@rz.uni-regensburg.de>:
> >>>> Michael Biebl  schrieb am 09.05.2019 um 12:29 in 
> >>>> Nachricht
> > :
> > > Am Do., 9. Mai 2019 um 12:27 Uhr schrieb Ulrich Windl
> > > :
> > >>
> > >> Hi!
> > >>
> > >> Whenever I try to enable or disable a target (that exists), I get 
> > >> "Failed to
> >
> > > execute operation: No such file or directory". What file or directory,
> > > please? Or what is the command trying to say?
> > >
> > > Can you share the target unit please.
> > > Into what location have you installed the unit file?
> >
> > This is after fixing obvious errors:
> > # systemctl enable iotwatch.target
> > Failed to execute operation: No such file or directory
> > # cat /run/systemd/generator.late/iotwatch.target
> > [Unit]
> > Description=iotwatch I/O performance monitor
> > Documentation=man:iotwatch@.service(8) man:iotwatch-generator(8)
> > After=nss-lookup.target time-sync.target paths.target
> > Wants=iotwatch@VAR.service
> >
> > [Install]
> > WantedBy=multi-user.target

This doesn't make sense. You generate an ephemeral runtime unit in
/run but you then try to enable it in /etc.

To make it easier to help, you should give us an idea/overview what
you are trying to achieve. What you did so far (and why), what
environment you are using etc.

It's really hard to give you a good answer when we don't even tell us
the systemd version and distro you are using.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Can I enable/disable a target?

2019-05-09 Thread Michael Biebl
[Please do not send this message to me privately only]

Am Do., 9. Mai 2019 um 13:22 Uhr schrieb Ulrich Windl
:
>
> >>> Michael Biebl  schrieb am 09.05.2019 um 12:29 in
> Nachricht
> :
> > Am Do., 9. Mai 2019 um 12:27 Uhr schrieb Ulrich Windl
> > :
> >>
> >> Hi!
> >>
> >> Whenever I try to enable or disable a target (that exists), I get "Failed
> to
> > execute operation: No such file or directory". What file or directory,
> > please? Or what is the command trying to say?
> >
> > Can you share the target unit please.
> > Into what location have you installed the unit file?
>
> Good question: I should have been created by a generator, so the location
> should be /run/systemd/generator*, but I could not find it. I have the feeling
> that "systemctl daemon-reload" did not trigger the generator (which is at
> /usr/lib/systemd/system-generators/iotwatch-generator).
>
> OK, trying to run the generator manually I found that it exits with 1, not
> creating the target. Wouldn't it be nice if systemd would log failed
> generators?

It does. You can find the log message in the journal.
See my other email

> So I fixed the generator (it can still exit with 1, but no longer in the
> success-case).
>
> Now I have some "bad" state:
> # systemctl status iotwatch.target
>  ● iotwatch.target - iotwatch I/O performance monitor
>Loaded: loaded (/run/systemd/generator.late/iotwatch.target; bad; vendor
> preset: disabled)
>Active: inactive (dead) since Thu 2019-05-09 12:39:45 CEST; 39min ago
> ...
>
> What is that "bad" referring to? The target
> /run/systemd/generator.late/iotwatch.target looks like this:
> # cat /run/systemd/generator.late/iotwatch.target
> [Unit]
> Description=iotwatch I/O performance monitor
> Documentation=man:iotwatch@.service(8) man:iotwatch-generator(8)
> After=nss-lookup.target time-sync.target paths.target
> Wants=iotwatch@VAR.service
>
> [Install]
> WantedBy=multi-user.target



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Any defined exit code for a generator?

2019-05-09 Thread Michael Biebl
Am Do., 9. Mai 2019 um 12:29 Uhr schrieb Ulrich Windl
:
>
> Hi!
>
> The manual page of generators does not talk about exit codes in case of an 
> error. Is there any handling of exit codes in systemd?

exit codes > 0 returned by the generator are treated as errors and
systemd will log about this when the generator is run. You'll get an
error message like this in the journal:

Mai 09 12:41:46 pluto systemd[1]: Reloading.
Mai 09 12:41:47 pluto systemd[5481]:
/lib/systemd/system-generators/test failed with exit status 1.

Can you be more specific about you are trying to do?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Can I enable/disable a target?

2019-05-09 Thread Michael Biebl
Am Do., 9. Mai 2019 um 12:27 Uhr schrieb Ulrich Windl
:
>
> Hi!
>
> Whenever I try to enable or disable a target (that exists), I get "Failed to 
> execute operation: No such file or directory". What file or directory, 
> please? Or what is the command trying to say?

Can you share the target unit please.
Into what location have you installed the unit file?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Arbitrary restrictions (e.g. for RuntimeDirectory)

2019-05-09 Thread Michael Biebl
Hi

Am Do., 9. Mai 2019 um 12:22 Uhr schrieb Ulrich Windl
:

> Despite of that I'm missing a "systemctl validate ..." command. That way I 
> wouldn't need to execute start, status, stop, just to find out that some 
> settings are rejected.

There is "systemd-analyze verify".

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Again, why this strange behavior implied by "auto" in fstab ?

2019-04-30 Thread Michael Biebl
Am Di., 30. Apr. 2019 um 11:20 Uhr schrieb Franck Bui :
> Just in case, this "feature" has been finally removed since v242 (commit 
> 42b8142d7).

I can't find a commit with that id
https://github.com/systemd/systemd/commit/42b8142d7

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Build only libsystemd as a shared library

2019-04-23 Thread Michael Biebl
Am Di., 23. Apr. 2019 um 17:51 Uhr schrieb Stanislav Angelovič
:
>
> Hi systemd-ers,
>
> Having recent systemd sources, how can I build libsystemd.so only?
>
> I was able to build the static version with this:
> meson build/
> ninja -C build version.h
> ninja -C build libsystemd.a
>
> But how can I build the shared one? Is there a configuration flag? (I'm not 
> familiar with meson.)
>
> In older, makefile-based systemd versions, I would just run:
> make built-sources
> make libsystemd.la
>
> I want to build libsystemd only because it contains sd-bus implementation and 
> sd-bus (and our sdbus-c++ layer on top of it) can thus be used also in 
> non-systemd environments (which is great).
>
> Thank you, have a nice day,

Depending on the version you are using
`ninja -C build/  libsystemd.so.0.26.0` should work

I used ninja -C build/ libsystemd fwiw.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] umount NFS problem

2019-04-05 Thread Michael Biebl
Am Fr., 5. Apr. 2019 um 08:45 Uhr schrieb Mantas Mikulėnas :

> The job order (home.mount vs nfs-client.target) already looks correct, so 
> fstab options probably won't help much; I'd try to ensure that the umount 
> doesn't fail in the first place.
>
> Normally I'd expect user sessions (user-*.slice, session-*.scope, 
> user@*.service) to be killed before mount units are stopped; I wonder how 
> random gpg-agent processes have managed to escape that. (Actually, doesn't 
> Debian now manage gpg-agent via user@.service? That *really* should be 
> cleaning up everything properly...)

I would check if libpam-systemd is installed and enabled.
Do you have remote logins via SSH? Does sshd_config have "UsePAM yes"

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd prerelease 242-rc2

2019-04-04 Thread Michael Biebl
fwiw, in Debian we added
https://salsa.debian.org/systemd-team/systemd/commit/b274b4ad5a4ba543c8c013fb71dacf2467030ddc

Am Do., 4. Apr. 2019 um 21:39 Uhr schrieb Mike Gilbert :
>
> On Thu, Apr 4, 2019 at 3:38 PM Mike Gilbert  wrote:
> >
> > On Thu, Apr 4, 2019 at 11:23 AM Lennart Poettering
> >  wrote:
> > >
> > > On Do, 04.04.19 10:06, Mike Gilbert (flop...@gentoo.org) wrote:
> > >
> > > > I pushed this out to our unstable testers yesterday, and received a
> > > > couple bug reports this morning. I have requested that they be
> > > > forwarded upstream, but wanted to point them out in case that doesn't
> > > > happen promptly.
> > > >
> > > > https://bugs.gentoo.org/682492
> > > > sys-apps/systemd-242_rc2 boot fails: sd-passwd takes no arguments
> > >
> > > Most likely fixed by
> > > https://github.com/systemd/systemd/commit/65e5d6934ec85febb6eb64e18ce829ddc9dee497
> > > already.
> > >
> > > > https://bugs.gentoo.org/682488
> > > > sys-apps/systemd-242_rc2: systemd-timesyncd.service: Failed to set up
> > > > special execution directory in /var/lib: Not a directory
> > >
> > > Smells like a belated result of us dropping DynamicUser=1 from
> > > timesyncd.
> > >
> > > Right now, systemd will automatically migrate the state directory for
> > > services that have DynamicUser=0 to a newer version that has
> > > DynamicUser=1, but not back. We should probably add that too.
> > >
> > > Anyway, it was systemd v240 where we dropped the DynamicUser=1 thing
> > > already, hence not precisely a v242 regression...
> >
> > These users probably upgraded from v239 to v241 to v242-rc2 over the
> > course of a few months. We never shipped v240.
>
> Sorry, I am mistaken; we did ship v240, but never marked it "stable".
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] looking for help to resolve shutdown problem

2019-04-04 Thread Michael Biebl
Am Do., 4. Apr. 2019 um 11:27 Uhr schrieb Michael Biebl :
>
> Am Do., 4. Apr. 2019 um 09:16 Uhr schrieb Harald Dunkel
> :
> > https://freedesktop.org/wiki/Software/systemd/Debugging/
> >
> > The promised /shutdown-log.txt file was not created (or I was too
> > blind to see).
>
> If systemd was compiled for a split-usr system (like in
> Debian/Ubuntu), the script needs to be placed in
> /usr/lib/systemd/system-shutdown/debug.sh (note the missing /usr).
>

Argh, obviously meant /lib/systemd/system-shutdown/debug.sh ...



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] looking for help to resolve shutdown problem

2019-04-04 Thread Michael Biebl
Am Do., 4. Apr. 2019 um 09:16 Uhr schrieb Harald Dunkel
:
> https://freedesktop.org/wiki/Software/systemd/Debugging/
>
> The promised /shutdown-log.txt file was not created (or I was too
> blind to see).

If systemd was compiled for a split-usr system (like in
Debian/Ubuntu), the script needs to be placed in
/usr/lib/systemd/system-shutdown/debug.sh (note the missing /usr).

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WantedBy=default.target

2019-03-07 Thread Michael Biebl
Am Do., 7. März 2019 um 15:47 Uhr schrieb Zbigniew Jędrzejewski-Szmek
:
>
> On Thu, Mar 07, 2019 at 11:31:18AM +0100, Michael Biebl wrote:
> > Am Do., 7. März 2019 um 11:24 Uhr schrieb Lennart Poettering
> > :
> > >
> > > On Do, 07.03.19 10:30, Michael Biebl (mbi...@gmail.com) wrote:
> > >
> > > > Looks like quite a few services use
> > > > WantedBy=default.target
> > > > https://codesearch.debian.net/search?q=WantedBy%3Ddefault.target
> > > >
> > > > Some of them are user services, but I wonder if there is
> > > > recommendation regarding system services.
> > > > Should they use multi-user.target or graphical.target instead or is it
> > > > ok for system services to hook into default.target?
> > >
> > > Usually doing this for system services is wrong, but there are
> > > exceptions.
> >
> > [..]
> >
> > > It might make sense to extend "systemd-analyze" in some form to warn
> > > about this, maybe file an RFE bug about that?
> >
> > I was considering filing a lintian bug, which would check debian
> > packages automatically for this.
> > Do we have documentation for this where I could point the lintian 
> > maintainer at?
>
> https://www.freedesktop.org/software/systemd/man/systemd.special.html#multi-user.target

I was looking for something which documents that default.target should
not be used in general for starting your service.
I.e. when it is ok to hook up your service in default.target and when
you should use multi-user.target or graphical.target.
Basically what Lennart explain above

Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WantedBy=default.target

2019-03-07 Thread Michael Biebl
Am Do., 7. März 2019 um 11:24 Uhr schrieb Lennart Poettering
:
>
> On Do, 07.03.19 10:30, Michael Biebl (mbi...@gmail.com) wrote:
>
> > Looks like quite a few services use
> > WantedBy=default.target
> > https://codesearch.debian.net/search?q=WantedBy%3Ddefault.target
> >
> > Some of them are user services, but I wonder if there is
> > recommendation regarding system services.
> > Should they use multi-user.target or graphical.target instead or is it
> > ok for system services to hook into default.target?
>
> Usually doing this for system services is wrong, but there are
> exceptions.

[..]

> It might make sense to extend "systemd-analyze" in some form to warn
> about this, maybe file an RFE bug about that?

I was considering filing a lintian bug, which would check debian
packages automatically for this.
Do we have documentation for this where I could point the lintian maintainer at?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] WantedBy=default.target

2019-03-07 Thread Michael Biebl
Looks like quite a few services use
WantedBy=default.target
https://codesearch.debian.net/search?q=WantedBy%3Ddefault.target

Some of them are user services, but I wonder if there is
recommendation regarding system services.
Should they use multi-user.target or graphical.target instead or is it
ok for system services to hook into default.target?

Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] taking time off

2019-01-15 Thread Michael Biebl
Will stop maintaining systemd in debian for a while.

What's going on is just too stupid/crazy.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] GithHub / private repos

2019-01-09 Thread Michael Biebl
Am Mi., 9. Jan. 2019 um 21:24 Uhr schrieb Michael Biebl :
>
> https://blog.github.com/2019-01-07-new-year-new-github/
>
> might be of interest given the recent discussions how to handle security 
> issues.

Answering to myself: With the restriction of 3 developers per private
repository, it's probably not particularly useful for this case.

Too bad :-/
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] GithHub / private repos

2019-01-09 Thread Michael Biebl
https://blog.github.com/2019-01-07-new-year-new-github/

might be of interest given the recent discussions how to handle security issues.

Regards,
Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Disable message "A start job is running for myservice"

2018-12-10 Thread Michael Biebl
Am Mo., 10. Dez. 2018 um 14:26 Uhr schrieb Lennart Poettering
:
>
> On Mo, 10.12.18 13:47, Paolo Minazzi (paolo.mina...@mitrol.it) wrote:
>
> > but these parameter cannot modify the behaviour.
> > Is there some way to do it ?
>
> No there is not. This is compiled in and global. You can turn off all
> status output though…

It's hard-coded in
https://github.com/systemd/systemd/blob/master/src/core/manager.c#L87

I thought the eye-of-cylon message kicked in automatically, even if
status messages were turned off (say via quiet)?



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] How to handle alias and sysv init enable/disable (mariadb/mysql)

2018-11-10 Thread Michael Biebl
Am Sa., 10. Nov. 2018 um 20:04 Uhr schrieb Michael Biebl :
> ... in Debian, to be clear.

I updated 
https://wiki.debian.org/Teams/pkg-systemd/Packaging#systemd_unit_files_naming_and_installation
a bit. Hope it's helpful. Let me know if it needs further clarifications.

Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] How to handle alias and sysv init enable/disable (mariadb/mysql)

2018-11-10 Thread Michael Biebl
Am Sa., 10. Nov. 2018 um 19:59 Uhr schrieb Michael Biebl :
>
> Am Sa., 10. Nov. 2018 um 19:56 Uhr schrieb Michael Biebl :
> >
> > My recommendation would be, to not create the myslq(d).service alias
> > dynamically via
> > [Install]
> > Alias=mysql.service
> > Alias=mysqld.service
> >
> > but ship it as a static symlink in the package
>
> As an example:
> Historically, the init script for NetworkManager has been called
> /etc/init.d/network-manager but I decided to keep the upstream name

... in Debian, to be clear.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] How to handle alias and sysv init enable/disable (mariadb/mysql)

2018-11-10 Thread Michael Biebl
Am Sa., 10. Nov. 2018 um 19:56 Uhr schrieb Michael Biebl :
>
> My recommendation would be, to not create the myslq(d).service alias
> dynamically via
> [Install]
> Alias=mysql.service
> Alias=mysqld.service
>
> but ship it as a static symlink in the package

As an example:
Historically, the init script for NetworkManager has been called
/etc/init.d/network-manager but I decided to keep the upstream name
NetworkManager.service for the systemd .service unit.
Which is why I ship

 ls -al /lib/systemd/system/network-manager.service
lrwxrwxrwx 1 root root 22 Nov  5 16:05
/lib/systemd/system/network-manager.service -> NetworkManager.service

in the network-manager package.

This way, I always have the proper mapping between the legacy init
script and the service file.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] How to handle alias and sysv init enable/disable (mariadb/mysql)

2018-11-10 Thread Michael Biebl
Am Sa., 10. Nov. 2018 um 19:53 Uhr schrieb Faustin Lammler :
>
> Hi,
> sorry if this was already discussed but I can't find any
> pointer or documentation on how to handle this.
>
> This is the problem we are facing:
> https://jira.mariadb.org/browse/MDEV-15526
>
> It can be reproduced on Debian stretch by disabling mariadb service
> using 'systemctl disable mariadb' (all versions of mariadb are
> concerned).
>
> The problem is that this doesn't call the systemd-sysv-install script
> (to update /etc/init.d/rc?.d links) because there is no
> '/etc/init.d/mariadb' script but '/etc/init.d/mysql'. And on reboot
> mariadb is not disabled because it is started by '/etc/init.d/mysql'
> script.
>
> Of course calling 'systemctl disable mysql' does the job but we need
> both command acting the same way (mysql|mariadb).
>
> If you have any pointer/documentation or you know a similar project -
> that needs to maintain multiple name/alias for the same service - that
> would be a great help.

My recommendation would be, to not create the myslq(d).service alias
dynamically via
[Install]
Alias=mysql.service
Alias=mysqld.service

but ship it as a static symlink in the package
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] reliable way to check if udev is ready to serve requests

2018-10-11 Thread Michael Biebl
Am Do., 11. Okt. 2018 um 08:54 Uhr schrieb Lennart Poettering
:
>
> On Di, 09.10.18 22:24, Michael Biebl (mbi...@gmail.com) wrote:
>
> > Hi,
> >
> > is there a reliable way to check from a shell script that udevd is
> > running and able to serve request?
> > Say you want to run "udevadm trigger" but only if udevd is actually
> > able to process that request.
> >
> > There is a udev_ctrl_send_ping() function, which looks like it could
> > be perhaps used for those. Unfortunately this is not exposed via
> > "udevadm control"
>
> systemctl is-running systemd-udevd-kernel.socket

I forgot to add, that systemd-udevd is not necessarily started by
systemd in this particular case. So I can't use systemctl...


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] reliable way to check if udev is ready to serve requests

2018-10-09 Thread Michael Biebl
Hi,

is there a reliable way to check from a shell script that udevd is
running and able to serve request?
Say you want to run "udevadm trigger" but only if udevd is actually
able to process that request.

There is a udev_ctrl_send_ping() function, which looks like it could
be perhaps used for those. Unfortunately this is not exposed via
"udevadm control"

Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Revert "meson: use the host architecture compiler/linker for src/boot/efi" #10217

2018-09-30 Thread Michael Biebl
Am So., 30. Sep. 2018 um 19:57 Uhr schrieb Helmut Grohne :
> I filed this build failure almost two months ago, see
> https://bugs.debian.org/905381. And the meson maintainer had me wait
> since April (close to when the breaking commit was introduced) to add
> the relevant tools to the cross file generator (see
> https://bugs.debian.org/895636). If a reported build problem with
> systemd can remain unfixed for almost half a year, then surely there is
> not the slightest need to rush this. Please hold off.

To be fair, you filed the "Debian" bug report 2 months ago and I told
you to file this upstream, which you did not do.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] exim4 only queues mails sent by systemd service

2018-09-24 Thread Michael Biebl
Am So., 23. Sep. 2018 um 22:49 Uhr schrieb Kamil Jońca :
>
> It is something strange with sending mails from systemd system service:
> assume we have service file /etc/systemd/system/mailtest.service:
>
> --8<---cut here---start->8---
> [Unit]
> Description="Test maili"
> [Service]
> #User=kjonca
> NoNewPrivileges=false
> Type=oneshot
> ExecStart=-zsh -c 'echo xxx|mail news'
> ExecStart=-zsh -c 'echo xxx|mutt -F /dev/null -s subject -e \'set copy=no\' 
> kjonca'
> --8<---cut here---end--->8---
>
> When I call
> sudo systemctl start mailtest.service
> Two messages are put in exim queue, but not deliveried immediately.
> Why? What am I missing?

Fwiw, I tried your example service file, works for me.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] blocking service on shutdown

2018-09-05 Thread Michael Biebl
Am Di., 4. Sep. 2018 um 18:53 Uhr schrieb Ralf Sieger :
>
> Well, it does wait when I press the power button on the case.
> It does not wait if I enter as root poweroff or reboot.
> I assume the first one goes through the logind while the second case does 
> straight to systemd...
>

You are correct. Inhibitors (currently) only block if the request
comes from an unprivileged user.
I guess the reason behind that is, that you could circumvent that
anyway, if you are root.

See https://github.com/systemd/systemd/issues/2680

Personally I would find it useful if systemd-inhibit would have a
switch to also respect inhibitors for root.



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] blocking service on shutdown

2018-09-04 Thread Michael Biebl
2018-09-04 18:17 GMT+02:00 Ralf Sieger :
> Hi Michael,
>
> this solution has a couple of drawbacks:
> - block will let shutdown, etc. fail, I do only need a pause/wait

> - delay does not work with reboot

It should work for shutdown, i.e. reboot.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] blocking service on shutdown

2018-09-02 Thread Michael Biebl
2018-09-02 15:37 GMT+02:00 Ralf Sieger :
> Hi,
>
> I want my system to pause on shutdown to wait till my backup has finished if
> it is running.

I would suggest using an inhibitor lock when running your backup.
See https://www.freedesktop.org/wiki/Software/systemd/inhibit/

That's exactly the use-case it was designed for.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Select on value of log message

2018-08-30 Thread Michael Biebl
I don't want to use systemd as a stick to beat people^maintainers with
Am Do., 30. Aug. 2018 um 18:56 Uhr schrieb Uoti Urpala
:
>
> On Thu, 2018-08-30 at 16:39 +0200, Michael Biebl wrote:
> > Am Do., 30. Aug. 2018 um 15:50 Uhr schrieb Jérémy Rosen <
> > jeremy.ro...@smile.fr>:
> > > I *think* that it's deactivated in debian because journalctl is a
> > > core package and debian doesn't want to pull the regex library into
> > > it's core...
> > >
> >
> > Right, no need to file another bug report.
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890265
>
> OTOH the older libpcre is currently necessary due to dependencies such
> as grep, and the packages say people should migrate to libpcre2. So IMO
> it'd be reasonable to add a libpcre2 dependency, and respond to any
> complaints by saying that if people want to remove a pcre library, they
> should migrate the packages using the old version, so it could be
> removed instead.
>
> Keeping code using an up-to-date dependency disabled because other
> packages haven't been updated seems backwards...
>
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Select on value of log message

2018-08-30 Thread Michael Biebl
Am Do., 30. Aug. 2018 um 15:50 Uhr schrieb Jérémy Rosen <
jeremy.ro...@smile.fr>:

> I *think* that it's deactivated in debian because journalctl is a core
> package and debian doesn't want to pull the regex library into it's core...
>

Right, no need to file another bug report.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890265
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] udev script can't resolve host name

2018-08-15 Thread Michael Biebl
Am Mi., 15. Aug. 2018 um 11:09 Uhr schrieb Jonathan Kamens :
>
> Hi,
>
> If I understand correctly, this mailing list can be used for questions about 
> udev as well as about systemd. If that's not correct, somebody please let me 
> know and I will go elsewhere (and if you know where that "elsewhere" should 
> be, please let me know, that would be helpful!); I don't mean to use the list 
> incorrectly.
>
> I want to call a webhook inside a script run via a RUN directive in a udev 
> rule.

Consider using SYSTEMD_WANTS instead of calling (potentially long
running or privileged) tasks from udev rules.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Best way to run upstream systemd

2018-07-18 Thread Michael Biebl
2018-07-19 1:46 GMT+02:00 Ryan Gonzalez :
> The fastest any distro is going to get systemd would probably be from a
> bleeding-edge distro (e.g. Fedora Rawhide). If you don't want you system to
> be a disaster zone, though, Arch got systemd 237 just two weeks after
> release.
>
> Fedora will push systemd releases with their new versions, which come out
> every six months, and I believe non-LTS Ubuntu distros are probably the
> same.
>
> Anything LTS though (like Ubuntu LTS, Debian, or your own CentOS) is going
> to be the absolute *worst* for getting pretty much anything new...
>

Keep in mind that Fedora Rawhide is the development branch of fedora.
If you are open to that, you can just as well also use Debian sid,
which usually get's new systemd releases within a couple of days (e.g.
v239 was realised 22.6.18, uploaded to Debian a couple hours later at
23.6.18).
Those uploads then migrate to Debian testing automatically after a few
days, if no regressions are found.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] upower fails with PrivateNetwork=true

2018-07-07 Thread Michael Biebl
2018-07-06 13:23 GMT+02:00 Lennart Poettering :
> Yes, Mantas is right, PrivateNetwork= disconnects the whole of
> AF_NETLINK from the rest of the system, which means services that
> require libudev device events can't use it.

Thank you Lennart and Mantas.
I was indeed not aware that PrivateNetwork=true has that effect wrt AF_NETLINK.
Thanks for the explanation, this makes it perfectly clear now.
It's indeed a pitfall one has to keep in mind when using PrivateNetwork=

Tbh, I find it a bit confusing that we have three mechanisms now
(PrivateNetwork, RestrictAddressFamilies, IPAddressDeny) and when one
is supposed to use which one of these.

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] upower fails with PrivateNetwork=true

2018-07-05 Thread Michael Biebl
Hi,

in the latest upower release 0.99.8, the systemd service file was
locked down considerably[1]. Unfortunately, a result of that is, that
upower no longer detects any plug/unplug events [2].
Through some trial and error I found that it's the addition of
PrivateNetworks=true which broke upower.
Now I'm a bit puzzled why upower would need network to function properly.

Any ideas on what's going on there?

Michael

[1] 
https://gitlab.freedesktop.org/upower/upower/commit/b0cdb7e9fe93b662d4f4a29b3af7f66ef3763c67
[2] https://gitlab.freedesktop.org/upower/upower/issues/68
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] How to build only udev

2018-07-04 Thread Michael Biebl
arm64 is on a different archive in Ubuntu. You'll need to add

deb [arch=arm64] http://ports.ubuntu.com/ xenial main universe

to your /etc/apt/sources.list

After an "apt update", libudev-dev:arm64 should be available.

2018-07-04 21:42 GMT+02:00 Kevin Greene :
> Thanks Simon. I have tried doing that actually, but the arm64 version
> doesn't seem to be available. I'm on Ubuntu 16.04 fwiw.
>
> Here's the output I get from trying to install it:
> 
> $ sudo apt-get install libudev-dev:arm64
> [sudo] password for kevin:
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Package libudev-dev:arm64 is not available, but is referred to by another
> package.
> This may mean that the package is missing, has been obsoleted, or
> is only available from another source
>
> E: Package 'libudev-dev:arm64' has no installation candidate
> 
>
> I have installed other arm64 binaries for cross-compiling, so I'm not sure
> why the libudev-dev package isn't installable. For that matter, I'd like to
> not build libusb from source either, but it has the same problem.
>
> 2018-07-04 12:34 GMT-07:00 Simon McVittie :
>>
>> On Wed, 04 Jul 2018 at 11:36:23 -0700, Kevin Greene wrote:
>> > 2018-07-03 18:18 GMT-07:00 Mike Gilbert :
>> > Why not just install the libudev-dev package on a Ubuntu dev
>> > system/chroot? That would be much simpler than building libudev from
>> > scratch, and would ensure you build against the actual library
>> > Ubuntu
>> > uses.
>> >
>> >
>> > I appreciate the suggestion. I would definitely much prefer to do that,
>> > but
>> > I'm cross-compiling, and there doesn't appear to be a way to install
>> > arm64
>> > libudev-dev on x86_64
>>
>> You can add arm64 as a "foreign architecture" and install the arm64
>> libudev-dev that way, in a chroot/container that is based on the same
>> release of Ubuntu as your target platform, but amd64 (x86_64) instead
>> of arm64:
>>
>> sudo dpkg --add-architecture arm64
>> sudo apt-get update
>> sudo apt-get install libudev-dev:arm64
>>
>> (Depending on the Ubuntu release of interest, you might also be able
>> to install an entire cross-toolchain by installing
>> crossbuild-essential-arm64 in the same chroot/container.)
>>
>> See also
>>
>> https://enricozini.org/blog/2017/debian/qt-cross-architecture-development-in-debian/
>> (that's Debian armhf not Ubuntu arm64, but the principle is the same).
>>
>> smcv
>> ___
>> systemd-devel mailing list
>> systemd-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
>
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] How to guarantee the stdout buffer between systemd and journald is flushed when program quits?

2018-05-17 Thread Michael Biebl
2018-05-17 23:02 GMT+02:00 Ivan Kurnosov :

> Here is the example of the `journald` output for the service:

I assume you used journalctl -u bla.service?
If so, do the log messages turn up if you run journalctl?

Then this might be another instance of
https://github.com/systemd/systemd/issues/2913

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Running “telinit u” on glibc update

2018-05-16 Thread Michael Biebl
Hi Florian

2018-05-16 15:01 GMT+02:00 Florian Weimer :
> In Fedora, for historic reasons, we run “/sbin/telinit u” after installing a
> new glibc RPM package version.
>
> Does this still make sense?  Should we remove the code which invokes telinit
> from the glibc package?

We had something similar in the Debian glibc package
The background is in this bug report
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=753725

Afaiu, the telinit u was originally added so sysvinit can shutdown
cleanly and there were no open fds:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=25444

But this is not an issue with systemd/systemd-shutdown.
As the daemon-reexec was causing issues in Debian, we decided to
remove it from the glibc postinst.

Regards,
Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] "CVE-2013-4392: TOCTOU race condition when updating file permissions and SELinux security contexts" still an issue

2018-03-24 Thread Michael Biebl
Hi,

the Debian systemd package has an open bug report
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725357
about
CVE-2013-4392: TOCTOU race condition when updating file permissions
and SELinux security contexts

This references https://bugzilla.redhat.com/show_bug.cgi?id=859060
which never was properly closed afaics. So I wonder if this issue is
still relevant or was this fixed in another way?

Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd-shutdown: Failed to parse /proc/self/moutinfo

2018-03-13 Thread Michael Biebl
My problem is sooo important, I need to pester the whole systemd-devel
mailing list with a regular bug report.

2018-03-13 16:54 GMT+01:00 Reindl Harald :
> see https://bugzilla.redhat.com/show_bug.cgi?id=1554943 including screenshot
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Hints for upgrading systemd on a running system

2018-02-20 Thread Michael Biebl
2018-02-20 20:00 GMT+01:00 Paul Menzel :
>
> Do I need to stop those manually beforehand, or is there another way to
> clean up?

reboot.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] how to debug failures when trying to lock down services

2017-12-01 Thread Michael Biebl
2017-11-30 18:24 GMT+01:00 Lennart Poettering :
> On Do, 30.11.17 10:35, Mantas Mikulėnas (graw...@gmail.com) wrote:
>
>> Then I'm guessing ProtectSystem=strict overrides ReadWritePaths and makes
>> /var/log read-only...
>
> Hmm, it does? It really shouldn't.
>
> I thought the issues were mostly around InaccessiblePaths= not
> permitting exclusions, not about ProtectSystem/ReadOnlyPaths...
>
> Have a link?

I think I can reproduce that with v235. I think it works with git
master, but I need to verify that.




-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] how to debug failures when trying to lock down services

2017-11-30 Thread Michael Biebl
2017-11-30 16:07 GMT+01:00 Michael Biebl <mbi...@gmail.com>:
> 2017-11-30 9:35 GMT+01:00 Mantas Mikulėnas <graw...@gmail.com>:
>> On Thu, Nov 30, 2017 at 10:31 AM, Michael Biebl <mbi...@gmail.com> wrote:
>>>
>>> 2017-11-30 6:52 GMT+01:00 Mantas Mikulėnas <graw...@gmail.com>:
>>> > On Thu, Nov 30, 2017 at 5:27 AM, Michael Biebl <mbi...@gmail.com> wrote:
>>> >>
>>> >> [Service]
>>> >> ProtectHome=yes
>>> >> PrivateTmp=yes
>>> >> PrivateDevices=yes
>>> >>
>>> >> ProtectSystem=strict
>>> >> ReadWritePaths=/var/log
>>> >> ReadWritePaths=/var/spool/rsyslog
>>> >> ReadWritePaths=/proc/kmsg
>>> >
>
>>>
>>> I suspect it's related to ProtectSystem=strict, as with
>>> ProtectSystem=full rsyslog seems to start successfully. But this is
>
>> Then I'm guessing ProtectSystem=strict overrides ReadWritePaths and makes
>> /var/log read-only... I think I've seen other people have that problem
>> recently.
>
>
> *facepalm*
> rsyslog.service by default uses StandardOutput=null, so I didn't see
> the error messages in debug mode.
>
> After fixing that, it was rather obvious.
>
> *double facepalm*
> rsyslog writes a pid file in /run and fails to start if it can't write
> the pidfile.  I will raise this upstream that maybe writing a pidfile
> in socket activation / sd_notify mode is not really necessary and it
> should stop doing that.

Filed https://github.com/rsyslog/rsyslog/issues/2143 for that

> For now I used RuntimeDirectory=rsyslog and
> ExecStart=/usr/sbin/rsyslogd -n -i /run/rsyslog/rsyslogd.pid
>
> So the complete rsyslog.service now looks like
>
> [Unit]
> Description=System Logging Service
> Requires=syslog.socket
> Documentation=man:rsyslogd(8)
> Documentation=http://www.rsyslog.com/doc/
>
> [Service]
> Type=notify
> ExecStart=/usr/sbin/rsyslogd -n
> StandardOutput=null
> Restart=on-failure
>
> PrivateTmp=yes
> PrivateDevices=yes
> ProtectHome=yes
> ProtectSystem=strict
> ReadWritePaths=/var/log
> ReadWritePaths=/var/spool/rsyslog
> ReadWritePaths=/proc/kmsg
> ReadWritePaths=/tmp
>
> RuntimeDirectory=rsyslog
>
> CapabilityBoundingSet=CAP_SYSLOG
> CapabilityBoundingSet=CAP_NET_BIND_SERVICE
>
> ExecStart=/usr/sbin/rsyslogd -n -i /run/rsyslog/rsyslogd.pid
>
> [Install]
> WantedBy=multi-user.target
> Alias=syslog.service
>
> Feedback welcome on how to reasonably lock down rsyslog by default
> without breaking commonly used functionality (like remote syslog)
>
> Regards,
> Michael
> --
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] how to debug failures when trying to lock down services

2017-11-30 Thread Michael Biebl
2017-11-30 6:52 GMT+01:00 Mantas Mikulėnas <graw...@gmail.com>:
> On Thu, Nov 30, 2017 at 5:27 AM, Michael Biebl <mbi...@gmail.com> wrote:
>>
>> Hi,
>>
>> today I tried to lock down the rsyslog.service that I have on my system.
>>
>> For that I first created an override.conf that contained
>>
>> [Service]
>> ProtectHome=yes
>> PrivateTmp=yes
>> PrivateDevices=yes
>>
>> ProtectSystem=strict
>> ReadWritePaths=/var/log
>> ReadWritePaths=/var/spool/rsyslog
>> ReadWritePaths=/proc/kmsg
>
>
> Are you using imklog or imkmsg? The latter would require the new /dev/kmsg
> interface (which probably conflicts with PrivateDevices= above).

I suspect it's related to ProtectSystem=strict, as with
ProtectSystem=full rsyslog seems to start successfully. But this is
just trial and error.

>>
>> Unfortunately, rsyslog.service failed to start:
>> ● rsyslog.service - System Logging Service
>>Loaded: loaded (/lib/systemd/system/rsyslog.service; enabled;
>> vendor preset: enabled)
>>   Drop-In: /etc/systemd/system/rsyslog.service.d
>>└─override.conf
>>Active: failed (Result: exit-code) since Thu 2017-11-30 04:25:03 CET;
>> 2s ago
>>  Docs: man:rsyslogd(8)
>>http://www.rsyslog.com/doc/
>>   Process: 2734 ExecStart=/usr/sbin/rsyslogd -n (code=exited,
>> status=1/FAILURE)
>>  Main PID: 2734 (code=exited, status=1/FAILURE)
>
>
> Well, it does say that the failure comes from rsyslogd itself, not from the
> namespace setup...
>
>>
>> The journal doesn't contain anything useful.
>
>
> I'm guessing rsyslog will log its own errors to /var/log/syslog rather than
> stderr.

I don't have anyting in /var/log/syslog

>>
>> Any hints how I can further debug this why rsyslog fails to start?
>
>
> rsyslogd -d -d -d

Already tried that, doesn't produce any useful logs.


> strace

Already tried
ExecStart=
ExecStart=/usr/bin/strace -f -o /var/log/strace /usr/sbin/rsyslogd -n

but this didn't produce any /var/log/strace log file.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


  1   2   3   4   5   6   >