On Mon, 3 Apr 2023, Lennart Poettering wrote:
> On Sa, 01.04.23 06:16, Michael Chapman (m...@very.puzzling.org) wrote:
>
> > > Well, in larger environments the goal is typically to saturate all
> > > hosts, but not overload them. i.e. maximizing your ROI. No need to
>
On Sat, 1 Apr 2023, Uoti Urpala wrote:
> On Sat, 2023-04-01 at 06:16 +1100, Michael Chapman wrote:
> > On Fri, 31 Mar 2023, Lennart Poettering wrote:
> > [...]
> > > Presumably your system mmaps ELF binaries, VM images, and similar
> > > stuff into memory. if
On Fri, 31 Mar 2023, Lennart Poettering wrote:
[...]
> Presumably your system mmaps ELF binaries, VM images, and similar
> stuff into memory. if you don't allow anonymous memory to backed out
> onto swap, then you basically telling the kernel "please page out
> my program code out instead". Which
On Fri, 31 Mar 2023, Lennart Poettering wrote:
> On Fr, 31.03.23 07:57, Michael Chapman (m...@very.puzzling.org) wrote:
>
> > On Fri, 31 Mar 2023, Luca Boccassi wrote:
> > [...]
> > > No, it does not make "little difference", there are entire subs
On Fri, 31 Mar 2023, Lennart Poettering wrote:
> On Fr, 31.03.23 18:24, Michael Chapman (m...@very.puzzling.org) wrote:
>
> > On Fri, 31 Mar 2023, Barry wrote:
> > [...]
> > > If you want to run in ram only then you must turn off the kernel
> >
On Fri, 31 Mar 2023, Lennart Poettering wrote:
> On Do, 30.03.23 18:56, Michael Chapman (m...@very.puzzling.org) wrote:
>
> > On Thu, 30 Mar 2023, Lennart Poettering wrote:
> > > On Mi, 29.03.23 13:53, Christoph Anton Mitterer (cales...@scientia.org)
> > > wrote:
On Fri, 31 Mar 2023, Tomasz Torcz wrote:
> On Fri, Mar 31, 2023 at 06:24:09PM +1100, Michael Chapman wrote:
> > On Fri, 31 Mar 2023, Barry wrote:
> > [...]
> > > If you want to run in ram only then you must turn off the kernel
> > > overcommit.
> > >
On Fri, 31 Mar 2023, Barry wrote:
[...]
> If you want to run in ram only then you must turn off the kernel overcommit.
> Have you done that? If not then you risk processes getting SEGV signals.
Seriously. It's almost as if nobody here is actually reading anything of
what I've written!
On Fri, 31 Mar 2023, Phillip Susi wrote:
>
> Michael Chapman writes:
>
> > What specifically is the difference between:
> >
> > * swap does not exist at all;
> > * swap is full of data that will not be swapped in for weeks or months;
>
> T
On Fri, 31 Mar 2023, Luca Boccassi wrote:
[...]
> No, it does not make "little difference", there are entire subsystems
> which are much worse off, if not completely useless, without swap.
> Post-cgroupsv2 memory controller things are considerably different on
> this front, and old "common wisdom"
On Thu, 30 Mar 2023, Greg KH wrote:
> On Thu, Mar 30, 2023 at 09:09:19PM +1100, Michael Chapman wrote:
> > On Thu, 30 Mar 2023, Luca Boccassi wrote:
> > > On Thu, 30 Mar 2023 at 10:15, Michael Chapman
> > > wrote:
> > > >
> > > > On Thu, 30
On Thu, 30 Mar 2023, Luca Boccassi wrote:
> On Thu, 30 Mar 2023 at 10:15, Michael Chapman wrote:
> >
> > On Thu, 30 Mar 2023, Lennart Poettering wrote:
> > > On Mi, 29.03.23 13:53, Christoph Anton Mitterer (cales...@scientia.org)
> > > wrote:
> > >
>
On Thu, 30 Mar 2023, Lennart Poettering wrote:
> On Mi, 29.03.23 13:53, Christoph Anton Mitterer (cales...@scientia.org) wrote:
>
> > > > That's a bad idea btw. I'd advise you not to do that: on modern
> > > > systems you want swap, since it makes anonymous memory reclaimable.
> > > > I
> > > >
On Thu, 22 Dec 2022, Andrei Borzenkov wrote:
> On Thu, Dec 22, 2022 at 11:17 AM Nicolas Pillot
> wrote:
> >
> > Hello
> >
> > I am wondering if i can dynamically plan jobs (once) using systemd timer.
> > What i mean by that is kind of replicating the usage of the 'at' command
> >
>
>
On Mon, 14 Nov 2022, Ulrich Windl wrote:
[...]
> Wow! never heard of that option. Is that a kind of target, or what is the
> mechanism?
> Which of the 196 (man -k systemd | wc -l) systemd-related manual pages would
> describe it? ;-)
A small correction to my previous email: this particular boot
On Mon, 14 Nov 2022, Ulrich Windl wrote:
[...]
> > Boot with "systemd.debug-shell" and use tty9 to investigate from the inside.
>
> Wow! never heard of that option. Is that a kind of target, or what is the
> mechanism?
> Which of the 196 (man -k systemd | wc -l) systemd-related manual pages
On Wed, 28 Sep 2022, Branko wrote:
> On Wed, 28 Sep 2022 19:07:14 +1000 (AEST)
> Michael Chapman wrote:
>
> 1. ExecSTart is relative to RootDirectory (at least for me).
>
> 2. I've just simpliefied my service file to equal yours - simle static
> executable in RootDirectory
On Wed, 28 Sep 2022, Branko wrote:
> OK. You have bound one path. Is the executable within it or is it
> irrelevant for the case ( and the executable is in /tmp) ?
No, the executable was in the chroot's root directory. That's why I
referred to it with:
ExecStart=/hello
You could put the
On Wed, 28 Sep 2022, Branko wrote:
> On Wed, 28 Sep 2022 18:11:14 +1000 (AEST)
> Michael Chapman wrote:
>
> Sure, but this example is kind of useless as it doesn't bind-mount
> anything into chroot.
Sure, but you didn't mention anything about bind mounts.
I added:
BindRea
> Is there a simple demo example that uses it that I could try ?
This worked for me:
$ cd /tmp/root
$ cat hello.c
#include
int main(void) {
puts("Hello, world!");
}
$ clang -static -o hello hello.c
$ cat /etc/systemd/system/hello.service
[Service]
On Thu, 22 Sep 2022, Ulrich Windl wrote:
> Hi!
>
> I wonder:
> # systemctl status i*
> ● inst-sys.service
>Loaded: not-found (Reason: No such file or directory)
>Active: inactive (dead)
>
> ● iptables.service
>Loaded: not-found (Reason: No such file or directory)
>Active:
On Fri, 4 Mar 2022, Ulrich Windl wrote:
> Hi!
>
> In SLES15 SP3 (systemd-246.16-7.33.1.x86_64) I have this effect, wondering
> whether it is a bug or a feature:
> When using "journalctl -b -g raid" I see that _ome_ matches are highlighted
> in red, but others aren't. For example:
> Mar 01
On Thu, 10 Feb 2022, Yolo von BNANA wrote:
> Hello,
>
> i read the following in an LPIC 1 Book:
>
> " If you’ve done any investigation into systemd.sockets, you may believe
> that it makes super servers like xinetd obsolete. At this point in time,
> that is not true. The xinetd super server
On Mon, 8 Nov 2021, Sean Nyekjaer wrote:
> Hi,
>
> Regarding,
> https://github.com/systemd/systemd/issues/21203
>
> I think the point of the issue missed when the issue got closed.
>
> We have a service that is changing configs for systemd-networkd and
> issuing a `systemctl restart
On Sat, 18 Sep 2021, Matt Zagrabelny wrote:
> Greetings,
>
> I believe the Debian package of mpd enables a --global .service and
> .socket unit for the mpd daemon/service.
>
> I'd like to mask that and install it just to a single --user service.
Why do you need to mask the socket and service at
On Sun, 29 Aug 2021, Nishant Nayan wrote:
> Awesome, thanks!
>
> Also, where can I find the code section where services And kernel logs to
> journald?
> After tracing from 'main' at journald.c I came across the part where
> various sockets are opened and validated (/run/systemd/journal/stdout,
>
On Sun, 29 Aug 2021, Nishant Nayan wrote:
> Also I was wondering where in the code does journald.config file changes
> are parsed?
> For example in the above code , the line :-
> if (s->storage == STORAGE_PERSISTENT)
> Here, s->storage corresponds to 'Storage' option of conf file right?
>
On Sun, 29 Aug 2021, Nishant Nayan wrote:
> I was looking into the code of systemd-journald and found this (in
> system_journal_open() ) :-
>
> if (!s->system_journal && IN_SET(s->storage, STORAGE_PERSISTENT,
> STORAGE_AUTO) && (flush_requested || flushed_flag_is_set())) {
>
> /* If
On Sun, 29 Aug 2021, Nishant Nayan wrote:
> I was looking into the code of systemd-journald and found this (in
> system_journal_open() ) :-
>
> if (!s->system_journal && IN_SET(s->storage, STORAGE_PERSISTENT,
> STORAGE_AUTO) && (flush_requested || flushed_flag_is_set())) {
>
> /* If
On Thu, 19 Aug 2021, Michael Chapman wrote:
> On Thu, 19 Aug 2021, Cristian Rodríguez wrote:
> > On Tue, Aug 17, 2021 at 9:35 PM 李成刚 wrote:
> > >
> > > How to configure this service so that it will not automatically exit
> >
> >
> > So what are yo
On Thu, 19 Aug 2021, Cristian Rodríguez wrote:
> On Tue, Aug 17, 2021 at 9:35 PM 李成刚 wrote:
> >
> > How to configure this service so that it will not automatically exit
>
>
> So what are you trying to accomplish with this ? why do you need yet
> another service running when it is totally idle ?
On Wed, 18 Aug 2021, Ulrich Windl wrote:
> >>> Michael Chapman schrieb am 18.08.2021 um 08:38 in
> Nachricht :
> > On Wed, 18 Aug 2021, Ulrich Windl wrote:
> >> >>> Michael Chapman schrieb am 17.08.2021 um 02:52
> in
> >> Nachricht &
On Wed, 18 Aug 2021, Ulrich Windl wrote:
> >>> Michael Chapman schrieb am 17.08.2021 um 02:52 in
> Nachricht <885331af-bb7-41d0-e8-26c92023b...@very.puzzling.org>:
> > On Tue, 17 Aug 2021, Dave Close wrote:
> >> I'm trying to run "systemctl show" in
On Tue, 17 Aug 2021, Dave Close wrote:
> I'm trying to run "systemctl show" in a cron script. It works but I get
> a huge number of extra lines in my log for each run. Why? Can this be
> suppressed. I don't want to overfill the log.
>
> There is nothing in the man page (that I noticed) indicating
On Sat, 17 Jul 2021, Mike Beaton wrote:
> > I've managed to get it to be called
> automatically on both Fedora and CentOS/Rocky 8
>
> Thank you. How? I'm not asking for excruciating detail, just roughly. Your
> own scripts, or something in the distribution?
On Fedora, the kernel-core RPM's
On Fri, 12 Mar 2021, Ulrich Windl wrote:
[...]
> > Can you think of a better way of wording the documentation?
>
> It depends: Do you consider /dev/log to be a "syslog socket"?
> (I'm not running rsyslog there)
I'm not quite sure what you mean. If where you're going is "well
*obviously*
On Fri, 12 Mar 2021, Ulrich Windl wrote:
> >>> Reindl Harald schrieb am 11.03.2021 um 16:23 in
> Nachricht <4422087b-9966-e7fb-66ad-4157d83f2...@thelounge.net>:
>
> >
> > Am 11.03.21 um 12:17 schrieb Ulrich Windl:
> >> Hi!
> >>
> >> I have a unit that uses logger, and I want to run it after
On Tue, 9 Feb 2021, Ulrich Windl wrote:
[...]
> OK, I tried (staring libvirtd.service with --listen and without --timout):
> Feb 09 10:59:23 h18 libvirtd[42540]: --listen parameter not permitted with
> systemd activation sockets, see 'man libvirtd' for further guidance
> Feb 09 10:59:23 h18
On Tue, 9 Feb 2021, Ulrich Windl wrote:
[...]
> >
> > libvirt can be run without socket activation [2]. I strongly recommend you
> > configure it this way if you intend to manage libvirt in Pacemaker.
>
> Yes, I'd like to! Any pointers?
Follow the link. It's all described there.
On Tue, 9 Feb 2021, Ulrich Windl wrote:
[...]
> At what timne exactly? When pacemaker starts, or when the systemd using is
> about to be started?
Pacemaker adds the drop-in just before it starts the resource, and it
removes the drop-in just after it stops the resource. It's entire purpose
is to
On Tue, 9 Feb 2021, Ulrich Windl wrote:
[...]
> As for the drop-ins: I neither know what those are expected to do, not who
> adds them at run time. See "documentation"...
The 50-pacemaker.conf drop-ins are, as their name suggests, created by
Pacemaker.
Specifically, Pacemaker's systemd resource
On Tue, 9 Feb 2021, Michael Chapman wrote:
[...]
> Note that when you're using Pacemaker to manage a systemd service, you
> should not enable the service in the normal way -- that is, the service
> should not be started simply by virtue of it being in the Wants= list of
> multi
On Sat, 5 Sep 2020, Richard Hector wrote:
> Hi all,
>
> Quoting from another thread:
>
> On 5/09/20 4:36 am, Lennart Poettering wrote:
> > Unit instances can be activated on-the-fly without further prepartion
> > or regsitration of the instance string or so. it's sufficient if the
> > template
On Sat, 27 Jun 2020, Mark Rogers wrote:
> On Sat, 27 Jun 2020 at 11:06, Zbigniew Jędrzejewski-Szmek
> wrote:
> > You should use Before=network-pre.target, Wants=network-pre.target.
>
> Thanks, tried that but still not working:
It could very well be because of the dhcpcd.service you're using.
I
On Mon, 18 May 2020, Debraj Manna wrote:
> Around the same time I am seeing the below error in syslog
>
> May 18 08:49:24 platform3 systemd[1]: Removed slice User Slice of support.
> May 18 08:49:27 platform3 systemd[1]: Assertion 's->type ==
> SERVICE_ONESHOT' failed at
On Sun, 17 May 2020, Andrei Borzenkov wrote:
> 17.05.2020 03:32, Michael Chapman пишет:
> > On Fri, 15 May 2020, Frank Steiner wrote:
> >> Hi,
> >>
> >> I need to run a script on shutdown before any other service is stopped.
> >> Due to an advice Le
On Sun, 17 May 2020, Michael Chapman wrote:
> On Fri, 15 May 2020, Frank Steiner wrote:
> > Hi,
> >
> > I need to run a script on shutdown before any other service is stopped.
> > Due to an advice Lennart gave a while ago I'm using this service file
> > (with mu
On Fri, 15 May 2020, Frank Steiner wrote:
> Hi,
>
> I need to run a script on shutdown before any other service is stopped.
> Due to an advice Lennart gave a while ago I'm using this service file
> (with multi-user.target being our default runlevel target):
>
> [Unit]
> After=multi-user.target
>
On Fri, 20 Mar 2020, Uwe Geuder wrote:
[...]
> > PathChanged= and PathModified= each map down to a set of inotify
> > events. It's the kernel's inotify system that determines whether the
> > file changed or modified, not systemd.
>
> My understanding is that since
>
On Fri, 20 Mar 2020, Uwe Geuder wrote:
[...]
> The manual page is not very specific about how that is supposed to work
> IMHO, but I could imagine the following distinction:
>
> PathExists=, PathExistsGlob=, and DirectoryNotEmpty= are absolute
> predicates. When setting the path unit to waiting
On Wed, 18 Mar 2020, Uwe Geuder wrote:
> Hi!
>
> I have wondered for a while how I can use *.path units without (too bad)
> races.
>
> Since
> https://github.com/systemd/systemd/pull/13509/commits/06582e42de65a61d0238a18720a12b6353edb7cd
> the behaviour has been become much clearer, but I must
On Thu, 12 Mar 2020, Jędrzej Dudkiewicz wrote:
[...]
> And one more question: what is systemd-timedated? It seems that is
> exactly same thing, but I don't think this is true?
It's the DBus service that most bits of timedatectl talk to. timedatectl
doesn't modify system configuration directly.
On Fri, 24 Jan 2020, Roger Pack wrote:
> Forgive me if this is too naive, but would it be possible for
> systemctl to "immediately start outputting logs" (journalctl type
> output) while it is in the middle of running a command? Ex: while
> running "systemctl stop my_server" it could show the
On Thu, 9 Jan 2020, Reindl Harald wrote:
> Hi
>
> deployed http.service contains:
>
> * InaccessiblePaths=-/usr/bin/bash
> * InaccessiblePaths=-/usr/bin/dash
> * InaccessiblePaths=-/usr/bin/sh
>
> now there is one instance where passthru() in a php script is desired
>
>
On Mon, 6 Jan 2020, Claes H wrote:
> Turns out the problem was not with the mount - that was working well.
> Instead it was a user problem and I did not realize the process ran as
> root and used a different home directory.
> When I added the user homeassistant in the host and added it to the
>
On Sat, 30 Nov 2019, Ankele zhang wrote:
> Hello All:
> How to execute shell before rootfs mounted on CentOS7.
> On CentOS6, we can modify init shell in initramfs.img to do something
> we need. But on CentOS7 my beloved init has be changed to systemd and
> systemd has no shell script.
On Thu, 26 Sep 2019, Hans de Goede wrote:
> Hi,
>
> On 26-09-2019 11:10, Michael Chapman wrote:
> > On Thu, 26 Sep 2019, Hans de Goede wrote:
> > [...]
> >> I believe that the best alternative is to have localed append / update
> >> a rd.vconsole.keymap
On Thu, 26 Sep 2019, Hans de Goede wrote:
[...]
> I believe that the best alternative is to have localed append / update
> a rd.vconsole.keymap=foo argument to the kernel commandline, to override
> the vconsole.conf KEYMAP setting, but only in the initrd (so that later
> runtime changes when
On Sun, 15 Sep 2019, Daniel Duong wrote:
> Hi,
>
> I have a 2 template units: 1 for a service and 1 for a socket. Each
> instance is a version of my web application.
>
> After a successful deploy, I stop and disable the old version and I
> enable the new one:
> systemctl start
On Mon, 16 Sep 2019, Reindl Harald wrote:
> Am 16.09.19 um 09:36 schrieb Zbigniew Jędrzejewski-Szmek:
> > Normally units should be unloaded immediately if they are stopped
> > and didn't fail. What systemd version are you using?
>
> the better question is which one are you using because this
On Tue, 3 Sep 2019, Chris Murphy wrote:
> Maybe it's something unique to gnome-shell segfaults, that's the only
> thing I have crashing right now. But I've got a pretty good reproducer
> to get it to crash and I never have any listings with coredumpctl.
>
> process segfaults but systemd-coredump
On Sat, 31 Aug 2019, Daniel Otero Oubiña wrote:
> I forgot to say that the devices on crypttab are also configured with
> `noauto`, that's why I was adding the dependences manually.
Even with `noauto`, the manual dependency isn't needed. The dependencies I
described were all about the block
On Fri, 30 Aug 2019, Daniel Otero Oubiña wrote:
> Hi all!
>
> I have found a somehow strange systemd "feature" that I'm not sure if it's
> a bug. Let me know if you prefer having this reported on GitHub instead.
>
> First, let me explain my setup: I have a data filesystem that is split in
> two
On Tue, 27 Aug 2019, Ulrich Windl wrote:
[...]
> > If you're not using the _netdev keyword, and systemd does not otherwise
> > think this is a remote filesystem, you will need to add this dependency
> > manually. You'll probably also want:
> >
> > Wants=network‑online.target
> >
On Tue, 27 Aug 2019, Tony Rodriguez wrote:
> Managed to detect/mount iscsi devices without using _netdev keyword in
> /etc/fstab. Made changes within src/fstab-generator/ftstab-generator.c and it
> seems to work. The only problem is during shutdown/reboot, my iscsi xfs
> filesystem does not
On Fri, 16 Aug 2019, Uoti Urpala wrote:
> On Thu, 2019-08-15 at 20:36 +1000, Michael Chapman wrote:
> > With systemd 239 I was unable to cause an fd leak this way.
> >
> > Still, I would feel more comfortable if I could find a commit that
> > defini
On Thu, 15 Aug 2019, Lennart Poettering wrote:
> On Mi, 14.08.19 22:36, Michael Chapman (m...@very.puzzling.org) wrote:
>
> > On Wed, 14 Aug 2019, Lennart Poettering wrote:
> > > Well, a D-Bus connection can remain open indefinitely, and may even
> > > have inc
On Wed, 14 Aug 2019, Lennart Poettering wrote:
> Well, a D-Bus connection can remain open indefinitely, and may even
> have incomplete "half" messages queued in them as long as the client
> desires. After the initial authentication is done, clients may thus
> take up resources as long as they
On Wed, 14 Aug 2019, Reindl Harald wrote:
> Am 14.08.19 um 12:41 schrieb Michael Chapman:
> > On Wed, 14 Aug 2019, Reindl Harald wrote:
> >> Am 14.08.19 um 12:10 schrieb Ulrich Windl:
> >>>>>> Michael Chapman schrieb am 14.08.2019 um
> >>>&g
On Wed, 14 Aug 2019, Reindl Harald wrote:
> Am 14.08.19 um 12:10 schrieb Ulrich Windl:
> >>>> Michael Chapman schrieb am 14.08.2019 um 11:47
> >>>> in
> >> That's all true, but the thing we need to check here is that systemd
> >> correc
On Wed, 14 Aug 2019, Ulrich Windl wrote:
> >>> Michael Chapman schrieb am 14.08.2019 um 11:47 in
> Nachricht :
> > On Wed, 14 Aug 2019, Lennart Poettering wrote:
> >> Quite frankly, invoking generic UNIX programs with fds < 3 closed is a
> >> really ba
On Wed, 14 Aug 2019, Lennart Poettering wrote:
> Quite frankly, invoking generic UNIX programs with fds < 3 closed is a
> really bad idea in general. That systemctl nowadays is particularly
> careful and deals with situations like that is not an invitation to
> actually invoke things like this.
On Wed, 14 Aug 2019, Michael Chapman wrote:
> On Wed, 14 Aug 2019, Brian Reichert wrote:
> > On Thu, Aug 01, 2019 at 07:18:20PM +, Zbigniew J??drzejewski-Szmek
> > wrote:
> > > Yes. (With the caveat that there *are* legitimate reasons to have new
> > > lon
On Wed, 14 Aug 2019, Brian Reichert wrote:
> On Thu, Aug 01, 2019 at 07:18:20PM +, Zbigniew J??drzejewski-Szmek wrote:
> > Yes. (With the caveat that there *are* legitimate reasons to have new
> > long-lived fds created, so not every long-lived fd is "wrong".)
>
> I finally was able to track
On Wed, 5 Jun 2019, Ulrich Windl wrote:
> >>> Reindl Harald schrieb am 04.06.2019 um 14:23 in
> Nachricht <4e4bc6ca-2637-b10d-f4f6-536f45264...@thelounge.net>:
>
> >
> > Am 04.06.19 um 14:17 schrieb Ulrich Windl:
> [...]
> > BTW: can you please only reply to the list instead reply all, your
> >
On Tue, 4 Jun 2019, Ulrich Windl wrote:
> >>> Michael Chapman schrieb am 04.06.2019 um 11:04 in
> Nachricht :
[...]
> > As you can see, even E.service was only started once.
> >
> > Are you sure you were actually doing everything in one transaction?
>
>
On Tue, 4 Jun 2019, Ulrich Windl wrote:
> >>> Michael Chapman schrieb am 03.06.2019 um 13:14 in
> Nachricht :
> [...]
> >
> > Um, OK. I don't think we're any closer to solving your problem though. :-)
>
> Actually I am!
> The root of the prob
On Mon, 3 Jun 2019, Ulrich Windl wrote:
> >>> Reindl Harald schrieb am 03.06.2019 um 12:35 in
> Nachricht :
>
> >
> > Am 03.06.19 um 12:30 schrieb Ulrich Windl:
> >>> That looks fine, though it _might_ make sense for it to have
> >>> RemainAfterExit= turned on. After all, if default.target or
On Mon, 3 Jun 2019, Ulrich Windl wrote:
>>>> Michael Chapman schrieb am 03.06.2019 um 11:39
> in
> Nachricht :
> > On Mon, 3 Jun 2019, Ulrich Windl wrote:
> > [...]
> >> Hi!
> >>
> >> The generator unit is:
> >>
On Mon, 3 Jun 2019, Ulrich Windl wrote:
[...]
> Hi!
>
> The generator unit is:
> [Unit]
> Description=I/O performance monitor instance generator
> Documentation=man:iotwatch-generator(8) man:iotwatch@.service(8)
> Wants=nss-user-lookup.target time-sync.target paths.target
>
On Mon, 3 Jun 2019, Ulrich Windl wrote:
> Hi!
>
> When installing a test package, I noticed that one unit
> (iotwatch-generator.service) triggered a restart for an unknown reason. The
> status is (note: no reason for restart shown):
>
> # systemctl status iotwatch-generator.service -l
> ●
On Mon, 3 Jun 2019, Andrei Borzenkov wrote:
> 03.06.2019 10:15, Ulrich Windl пишет:
> >>>> Michael Chapman schrieb am 31.05.2019 um 13:28
> >>>> in
> > Nachricht :
> >> On Fri, 31 May 2019, Reindl Harald wrote:
> >>> Am 31.05.1
On Mon, 3 Jun 2019, Ulrich Windl wrote:
[...]
> Where is the definitive documentation for these (rather new) RPM features?
https://rpm.org/user_doc/file_triggers.html
For Fedora specifically:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/
> And do all the major RPM-based
On Fri, 31 May 2019, Reindl Harald wrote:
[...]
> [harry@srv-rhsoft:/downloads/f28-f29]$ cat *.txt | grep -i "changed on disk"
> Warning: The unit file, source configuration file or drop-ins of
> mlocate-updatedb.timer changed on disk. Run 'systemctl daemon-reload' to
> reload units.
[...]
On Fri, 31 May 2019, Reindl Harald wrote:
> Am 31.05.19 um 12:31 schrieb Michael Chapman:
> > For RPM on Fedora, the systemd package has %transfiletriggerin and
> > %transfiletriggerun scriptlets that run automatically at the end of the
> > RPM transaction if units were
On Fri, 31 May 2019, Roger Pack wrote:
> Had a thought the other day...
>
> Seems like many packages (ex: rpm's) that includes a *.service file
> may eventually be required to call
>
> systemctl daemon-reload
>
> in the package, for new file changes to "take."
>
> This causes bugs like
>
...
>
> On Wed, 2 Jan 2019, Michael Chapman wrote
> >Make of that what you will. I was expecting a.service to stop because
> >b.service failed, but apparently my understanding of this isn't quite
> >right.
>
> Requires= alone without After= has interesting inte
On Wed, 2 Jan 2019, Reindl Harald wrote:
> Am 02.01.19 um 11:49 schrieb Michael Chapman:
> > On Wed, 2 Jan 2019, Reindl Harald wrote:
> > [...]
> >> agreed, but why can't have socket simply optional a [Service] section to
> >> save the "demo@.service"
On Wed, 2 Jan 2019, Reindl Harald wrote:
[...]
> agreed, but why can't have socket simply optional a [Service] section to
> save the "demo@.service" in cases like below?
>
> [root@client:/etc/systemd/system]$ cat demo.socket
> [Unit]
> Description=Demo Server - Activation Socket
>
> [Socket]
>
On Wed, 2 Jan 2019, Reindl Harald wrote:
> Am 02.01.19 um 09:14 schrieb Michael Chapman:
> > I have two services on my system, A.service and B.service, where A.service
> > Wants=B.service but is ordered Before=B.service. The reason for this is
> > that when I start A I want
On Wed, 2 Jan 2019, Jérémy Rosen wrote:
> So...
> >> Requires = Wants + PartOf
> >> Requires + After = Wants + PartOf + Requisite + After
> >>
> >> better ?
> >> My goal is to try to clarify that in the documentation at some point...
> > I don't think Requisite= comes into it at all.
> >
> >
On Wed, 2 Jan 2019, Jérémy Rosen wrote:
>
>
> On 02/01/2019 10:08, Michael Chapman wrote:
> >
> >> Requires = Wants + Requisite + PartOf
> >>
> >> is that correct ?
> > I think it's just:
> >
> >Requires = Wants + PartOf
> >
On Wed, 2 Jan 2019, Jérémy Rosen wrote:
>
> > In my opinion, I don't think the extra inconsistency we get from this is
> > worth it. It literally only saves one line in a unit file.
> >
> It's not about saving a line in the unit file, it's about avoiding errors on
> the most common case
>
> i.e
On Wed, 2 Jan 2019, Olaf van der Spek wrote:
> On Wed, Jan 2, 2019 at 9:14 AM Michael Chapman wrote:
> > > What good is an activation dependency without an ordering dependency?
> >
> > The problem is that it's not necessarily clear _which_ ordering dependency
> > i
On Wed, 2 Jan 2019, Zbigniew Jędrzejewski-Szmek wrote:
> On Wed, Jan 02, 2019 at 07:14:10PM +1100, Michael Chapman wrote:
[...]
> > The problem is that it's not necessarily clear _which_ ordering dependency
> > is required. systemd can't just assume one way or the other.
>
On Wed, 2 Jan 2019, Zbigniew Jędrzejewski-Szmek wrote:
> On Sun, Dec 30, 2018 at 12:05:46PM +0100, Olaf van der Spek wrote:
> > Hi,
> >
> > Evverx suggested I ask here @
> > https://github.com/systemd/systemd/issues/11284
> > It's about Requires and After. I think a unit in Requires should imply
On Wed, 2 Jan 2019, Jérémy Rosen wrote:
>
> >> What's the benefit of not having After= for those services?
> >I guess they can start and do their initialization in parallel with
> > the service they require.
> In that case, what is the benefit or Requires vs Wants ?
>
> I might be missing
On Wed, 2 Jan 2019, Olaf van der Spek wrote:
> On Wed, Jan 2, 2019 at 4:22 AM James Feeney wrote:
> > systemd has two different classes of "dependencies": 1) "activation"
> > dependencies, and 2) "ordering" dependencies.
> >
> > An activation dependency does not, a priori, have to obey any rules
On Tue, 1 Jan 2019, Olaf van der Spek wrote:
> Hi,
>
> AFAIK socket units require a separate file, which seems more complex
> then it has to be.
>
> 1. Could sockets be specified directly in the .service file?
If anything, I should think it would work the other way around: a .socket
without
On Tue, 13 Nov 2018, David Parsley wrote:
> I already scrub the environment when executing external scripts, and I've
> found that even after os.Unsetenv(...) the full environment is available to
> all processes owned by the robot in /proc//environ.
I'm a bit hesitent to enter this
1 - 100 of 194 matches
Mail list logo
