d reproduction using a newer version
if not the latest.
If the version is old and a newer one fixes it, I'd be inclined to try
bisecting for identifying which changes fixed it. But that assumes a
consistent ability to repro, and good vs. bad versions to work from.
Regards,
Vito Caputo
g because of
this weirdness. Overlayfs is kind of a dirty hack, but checks a few
desirable boxes, in a sea of inadequate in-kernel filesystems.
Not sure where OpenZFS stands here. It may be the bees-knees, perhaps
someone with experience can chime in?
Regards,
Vito Caputo
>
```
$ git tag --contains f12b399dd6362a03379cb769954ebfb9972236ed
v253-rc1
v253-rc2
```
It may make sense to create an issue regarding the docs @ freedesktop
being kept too up to date. It arguably shouldn't be publicizing
release candidate stuff no distro reasonably ships yet...
Regards,
V
247 is old, try updating systemd before going too crazy here - there's
been plenty of bugs fixed since then.
Regards,
Vito Caputo
No such file or directory
>
>
At a glance that path looks wrong, typically it's "lib/systemd/system/" not
"lib/system/system/"
Regards,
Vito Caputo
n serially in quick succession.
One could argue that if the underlying service is sharing these files,
it should probably be serializing access itself to prevent stepping on
its own toes. That would likely be done the same way using an
advisory lock on a shared file, maybe in a simple startup script using
flock as well.
Regards,
Vito Caputo
ad [0], also linked from [1].
Regards,
Vito Caputo
[0]
https://lists.freedesktop.org/archives/systemd-devel/2012-October/007054.html
[1] https://github.com/systemd/systemd/blob/v249/docs/JOURNAL_FILE_FORMAT.md
_journal_flush_matches().
>
> sd_journal_add_match( j , "F_1" , 4);
> sd_journal_add_match( j , "F_2" , 4);
> sd_journal_add_match( j , "F_4" , 4);
> N Filters
>
No, you only additively combin ematches in the existing API, simply
restarting
,
Vito Caputo
[0] https://github.com/systemd/systemd/blob/v247/src/journal/mmap-cache.c#L410
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
80 A56 d107+5 e480 A56 A56
d107+5 e480 A88 A56
---8<---8<---8<---8<
Regards,
Vito Caputo
[0] git://git.pengaru.com/jio (clone recursively w/--recursive)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
system, it's
less likely to have its allocations interrupted by allocations to
other writers.
To make meaningful measurements of fragmentation and the necessity of
telling the fs "hey, now's a good time to defrag this file I'm no
longer going to write to", you need to
On Thu, Nov 26, 2020 at 07:58:38PM +0100, Lennart Poettering wrote:
> On Mi, 25.11.20 19:02, Vito Caputo (vcap...@pengaru.com) wrote:
>
> > Hello systemd-devel,
> >
> > Recent discussion here about journal space consumption happened to
> > occur while I was exploring
m
3. what kind of information it produced
>
> Am 26.11.20 um 04:02 schrieb Vito Caputo:
> > Hello systemd-devel,
> >
> > Recent discussion here about journal space consumption happened to
> > occur while I was exploring use of the new io_uring linux kernel
> >
On Thu, Nov 26, 2020 at 11:25:22AM +, Dave Howorth wrote:
> On Wed, 25 Nov 2020 19:02:21 -0800
> Vito Caputo wrote:
>
> > I've called this program jio, pronounced "jai-oh".
>
> Silly question, but how is 'jai' pronounced?
The name is like saying the letters
lternative implementations may help improve
performance in this area.
Anyone interested in collaborating on this or sponsoring work in this
area feel free to contact me.
Cheers,
Vito Caputo
___
systemd-devel mailing list
systemd-devel@lists.freedesktop
to run journalctl -b under `valgrind
--tool=callgrind` and supply the callgrind.out? It would help
identify where the CPU time is being spent on that set of logs.
Regards,
Vito Caputo
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
not
going to happen as-is.
You might want to open an RFE issue requesting that the
FILE_SIZE_INCREASE define in journal-file be runtime configurable,
and/or clamped by the existing size limits.
Regards,
Vito Caputo
___
systemd-devel mailing list
systemd-devel@l
On Mon, Nov 16, 2020 at 08:18:28AM +0100, Ulrich Windl wrote:
> >>> Vito Caputo schrieb am 14.11.2020 um 21:29 in
> Nachricht
> <20201114202930.x7wbx4p37bkkw...@shells.gnugeneration.com>:
> > On Sat, Nov 14, 2020 at 09:31:23AM +, Nikolaus Rath wrote:
> >&
On Sat, Nov 14, 2020 at 12:29:30PM -0800, Vito Caputo wrote:
> On Sat, Nov 14, 2020 at 09:31:23AM +, Nikolaus Rath wrote:
> > Hello,
> >
> > I just discovered that on one of my systems journald only retains log
> > entries for about 10 days:
> >
> > #
s space per-file in 8MiB
increments.
On my laptop for example, there are 27 user journals, 8MiB each, where
the last object offset is around 2MiB. This alone burns ~162MiB in
allocated but unused space.
We should probably have some lower level tooling for scrutinizing
On Tue, Sep 29, 2020 at 06:05:00PM +0200, Michal Koutný wrote:
> On Mon, Sep 28, 2020 at 02:29:07PM -0700, Vito Caputo
> wrote:
> > Is it possible to either add a reclaimable field the total memory line
> > of `systemctl status` output?
> >
> > Or perhaps a separat
: ?
Is additional kernel memcg support required to make this possible?
(I admittedly haven't made any effort to explore implementation yet)
Thanks,
Vito Caputo
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman
Could you please stop signing mails sent to this publicly accessible,
archived, and indexed/searchable mailing list with this impossible
boilerplate:
> IMPORTANT: The contents of this email and any attachments are confidential.
> They are intended for the named recipient(s) only. If you have
On Mon, Jun 29, 2020 at 02:11:06PM -0500, Ian Pilcher wrote:
> On 6/29/20 2:00 PM, Vito Caputo wrote:
> > I don't know about freecusd, but if it uses a fire-and-forget approach
> > to launching helpers, as in it double-forks, so it doesn't need to
> > bother with asynchron
init processes job, to be a
process orphanage of sorts and reap orphaned processes.
Regards,
Vito Caputo
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
On Tue, Mar 31, 2020 at 03:32:04PM +0200, Lennart Poettering wrote:
> On Mo, 24.02.20 16:01, Vito Caputo (vcap...@pengaru.com) wrote:
>
> > Hello list,
> >
> > Today I experienced an unclean shutdown due to battery dying unexpectedly,
> > and it left my /var in a
On Wed, Feb 26, 2020 at 10:39:50AM +0100, Michael Biebl wrote:
> 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_
needs
improvement.
This is on an old release (v232) in Debian 9.11 amd64.
Regards,
Vito Caputo
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
On Fri, Oct 25, 2019 at 10:26:44AM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Thu, Oct 24, 2019 at 02:56:55PM -0700, Vito Caputo wrote:
> > On Thu, Oct 24, 2019 at 10:45:32AM +, Zbigniew Jędrzejewski-Szmek wrote:
> > > On Tue, Oct 22, 2019 at 04:35:13AM -0700,
On Thu, Oct 24, 2019 at 10:45:32AM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, Oct 22, 2019 at 04:35:13AM -0700, Vito Caputo wrote:
> > On Tue, Oct 22, 2019 at 10:51:49AM +, Zbigniew Jędrzejewski-Szmek wrote:
> > > On Tue, Oct 22, 2019 at 12:34:45PM +0200, Umut Tezdu
inite set used for
dispatching an upper-bound of concurrent async IO, just mlock most of
what it ever needs early on. But we're nowhere near that architecture
today, and that's really the kind of approach needed to make things
watchdog-appropriate with a minimum of false po
wise go unnoticed with background/idle
services, improving debugging substantially, but eliminate the problems
you describe resulting from false positives.
Regards,
Vito Caputo
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
On Sat, Sep 07, 2019 at 07:41:13PM +0200, Mikael Djurfeldt wrote:
> On Sat, Sep 7, 2019 at 7:26 PM Chuck Wolber wrote:
>
> > On Sat, Sep 7, 2019 at 10:17 Mikael Djurfeldt
> > wrote:
> >
> >>
> >> In any case, you can get rid of the watchdog altogether with an override.
> >>> Granted, you will
On Sat, Mar 23, 2019 at 11:59:57AM +0300, Andrei Borzenkov wrote:
> 22.03.2019 8:03, Vito Caputo пишет:
> > On Fri, Mar 22, 2019 at 06:46:21AM +0200, Mantas Mikulėnas wrote:
> >> Masking *is* local configuration. It's there so that the admin could
> >> simulate delet
g in when the time
comes to unmask it.
I'm surprised this requires any debate, nice top post btw.
>
> On Fri, Mar 22, 2019, 06:15 Vito Caputo wrote:
>
> > On Fri, Mar 22, 2019 at 07:06:30AM +0300, Andrei Borzenkov wrote:
> > > 22.03.2019 6:50, Vito Caputo пишет:
> &
On Fri, Mar 22, 2019 at 07:06:30AM +0300, Andrei Borzenkov wrote:
> 22.03.2019 6:50, Vito Caputo пишет:
> > On Thu, Mar 21, 2019 at 08:49:03PM -0700, Vito Caputo wrote:
> >> I have a local system unit file at /etc/systemd/system/foo.conf, which I
> >> need to mask
On Thu, Mar 21, 2019 at 08:49:03PM -0700, Vito Caputo wrote:
> I have a local system unit file at /etc/systemd/system/foo.conf, which I
> need to mask.
Correction: /etc/systemd/system/foo.service
>
> However, when I try to mask it systemctl complains:
>
> # systemctl --v
it?
Shouldn't `systemctl mask` work equally well for locally-configured
system units?
Regards,
Vito Caputo
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
On Tue, Mar 19, 2019 at 12:06:15PM +0100, Lennart Poettering wrote:
> On Mo, 18.03.19 17:04, Vito Caputo (vcap...@pengaru.com) wrote:
>
> > I'd personally appreciate being able to wire things up in my window
> > manager where I can run things via hotkeys like:
> >
&g
.
Thanks,
Vito Caputo
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
on this any further currently, but I think it
demonstrates the spirit of what I feel would be a great addition to
the journal consumption tooling.
If anyone wants to pick it up and run with it feel free, unless of
course there's already something out there I'm obvlivious of.
Cheers,
Vito Caputo
no accident that I've been able
to largely ignore systemd on my Debian machines updated over the years.
Thanks,
Vito Caputo
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
r QL3 test pool which contains hunderds of VM guests...
> It would be impractical to build and deploy a release which contains systemd
> running under valgrind on every node! :)
>
In such scenarios where valgrind's overhead is impractical, I'd give
address sanitizer a try.
https://clang.llvm.org/docs/AddressSanitizer.html
Regards,
Vito Caputo
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
is different.
>
I think another source of confusion in this situation is "udev"
containing the word "dev". I've only been skimming this thread as it
develops, but it seemed at times Sayeed is conflating the two to all be
development packages, perha
I missing?
>
Take a look at the machinectl man page, the "shell" and "login"
subcommands in particular.
Regards,
Vito Caputo
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
-disk
state.
I don't know why Chris is experiencing what he's seeing, it's not
something I have time to look more closely at right now. At a glance
though it seems suspect and worth investigating.
Regards,
Vito Caputo
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
care to comment.
Please find the forwarded message below.
Regards,
Vito Caputo
- Forwarded message from "Theodore Y. Ts'o" <ty...@mit.edu> -
Date: Tue, 1 May 2018 20:56:04 -0400
From: "Theodore Y. Ts'o" <ty...@mit.edu>
To: Sultan Alsawaf <sultan...@
---
src/core/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/core/main.c b/src/core/main.c
index d48604e..cd9d6ee 100644
--- a/src/core/main.c
+++ b/src/core/main.c
@@ -2013,7 +2013,7 @@ finish:
getpid() == 1 ? freezing : quitting);
Imagine running systemd --user post-CLONE_NEWPID to manage services in the
new namespace.
Cheers,
Vito Caputo
On Thu, Nov 6, 2014 at 2:56 PM, Lennart Poettering lenn...@poettering.net
wrote:
On Thu, 06.11.14 14:44, Vito Caputo (vito.cap...@coreos.com) wrote:
Hmm? What is this about? Why
?
Cheers,
Vito Caputo
On Thu, Nov 6, 2014 at 4:31 PM, Lennart Poettering lenn...@poettering.net
wrote:
On Thu, 06.11.14 16:26, Vito Caputo (vito.cap...@coreos.com) wrote:
Imagine running systemd --user post-CLONE_NEWPID to manage services in
the
new namespace.
But why not run
The capability of directly propagating a return code out to the caller of
systemd --user from within something like an OnFailure unit has utility.
This also contains a minor fixup to the documentation adding exit to the
--force section.
Cheers,
Vito Caputo
---
man/systemctl.xml | 11
51 matches
Mail list logo
