On 17/11/16 13:11, JEYARAJ wrote:
> Hi All,
>
> Dear Sir,
> I ,am installing job scheduling system for a single machine.munge also
> installed latest version.
> I start with Munge service .Error is showing;
>
> Again I used the command:
>
> Systemctl status munge.service
>
> Error is came.
On 25/11/16 22:47, Joel wrote:
> Lennart -
>
>
> Thank you for the reply.
>
>
> It's not clear whether you are instructing me to do something
> (restart journald or rebuild initrd) or asking a question.
If your distribution builds in the config file into the initrd, it's not
enough to simply
On 22/02/17 15:57, Reindl Harald wrote:
>
> please keep repsonses on the list
>
> Am 22.02.2017 um 15:42 schrieb Ian Pilcher:
>> On 02/21/2017 08:28 PM, Reindl Harald wrote:
>>> since this should be all on the LAN side something is *very* unusual on
>>> your setup - the firewall i setup at offi
I find your argument to be strange.
"The kernel has this functionality, please do not use it and rather
reimplement it in every piece of userspace that ever needs it, because
that's supposed to be more secure."
I simply don't buy your argument here.
//D.S.
On Mon, Mar 20, 2017 at 8:22 AM, Eric
So, I've got a piece of hardware I want to do a final handover to just
around reboot.target / shutdown.target
This will then cause the entire CPU and hardware allocated to it to
actually drop power (and schedule re-power), so I don't want to do this
earlier.
Is it simply to do:
[Unit]
DefaultD
On 27/10/17 12:25, Lennart Poettering wrote:
> On Fr, 27.10.17 11:43, D.S. Ljungmark (spi...@aanstoot.se) wrote:
>
>> So, I've got a piece of hardware I want to do a final handover to just
>> around reboot.target / shutdown.target
>>
>> This will then cause th
I seem to have the same problem, and here's the output:
[root@spring ~]# blkid -p /dev/sda1
/dev/sda1:
UUID="01c0c70f-9204-8e4e-f2a7-aa8ec14c4a41"
UUID_SUB="2a820238-597c-bfd4-aa2e-19425f7e8fa4"
LABEL="spring.skuggor.se:0" VERSION="1.0"
TYPE="linux_raid_member" USAGE="raid"
PART_ENTRY_SC
Right, and _that_ causes a far less interesting output from blkid.
/dev/md0: UUID="1492-1FE7" VERSION="FAT32" TYPE="vfat" USAGE="filesystem"
On Thu, Dec 14, 2017 at 11:53 AM, Lennart Poettering
wrote:
> On Do, 14.12.17 11:44, D.S. Ljungmark (spi...@
If you want I can bring a small form factor early x86 to Fosdem.
Industrial, rugged little things with x86 chipset was rather popular
for a while, and you can still order them new. The ones I have aren't
i486 but a 586 (cyrix, I think).
On Thu, Dec 28, 2017 at 8:26 PM, Reindl Harald wrote:
>
>
On Fri, Jan 5, 2018 at 6:47 AM, Reindl Harald wrote:
>
>
> Am 05.01.2018 um 05:51 schrieb D.S. Ljungmark:
>>
>> If you want I can bring a small form factor early x86 to Fosdem.
>>
>> Industrial, rugged little things with x86 chipset was rather popular
>> fo
Hi list!
We're using systemd to control the hardware watchdog, and would want to
induce fail state to _verify_ that the shutdown/reboot process works as
expected.
How do we make systemd "fail" to ping the watchdog?
How do we control which states ( root fs not available, etc) cause
systemd to no
( re-send as I forgot the list )
On 27/02/18 13:20, Lennart Poettering wrote:> On Di, 27.02.18 12:44,
D.S. Ljungmark (ljungm...@modio.se) wrote:
>
>> Hi list!
>>
>> We're using systemd to control the hardware watchdog, and would want to
>> induce fail state t
On 27/02/18 15:21, Lennart Poettering wrote:
> On Di, 27.02.18 15:12, D.S. Ljungmark (ljungm...@modio.se) wrote:
>
>>> I figure you can send SIGSTOP to PID 1, no? (there are some signals
>>> the kernel blocks for PID 1, but I think SIGSTOP is not among them,
>>>
ote:
> On Tue, Feb 27, 2018 at 6:25 PM, D.S. Ljungmark wrote:
>>
>>
>>
>> On 27/02/18 15:21, Lennart Poettering wrote:
>> > On Di, 27.02.18 15:12, D.S. Ljungmark (ljungm...@modio.se) wrote:
>> >
>> >>> I figure you can send SIGSTOP to PID
On Mon, 10 Sep 2018 at 21:13, Lennart Poettering
wrote:
> On Fr, 24.08.18 14:52, David Weinehall (david.weineh...@linux.intel.com)
> wrote:
>
> > We're having two time/date related issues/questions:
> >
> > First of all we'd need some counterpart to ntpdate.
> >
> > We have a system that lacks an
I've got the following unit:
[Unit]
Description=Random Submitter
Wants=network-online.target
After=network-online.target other.service
RequiresMountsFor=/data
[Service]
Type=simple
Environment=PYTHONPATH=/data
PrivateTmp=false
# Launches client config and others if needed
ExecStartPre=/usr/bin/pr
(re-send due to wrong email address)
On 24/09/15 14:38, Daniel Mack wrote:
> On 09/24/2015 01:17 PM, D.S. Ljungmark wrote:
>> I've got the following unit:
>>
>> [Unit]
>> Description=Random Submitter
>> Wants=network-online.target
>> After=network-onli
Hi,
we have a few services that are spamming a fair bit on DEBUG level of
log output. In syslog, we'd separate the DEBUG logs from the main log,
and set the rotation of DEBUG+ to be ~24 hours, while keeping INFO and
above for ~4 weeks.
How can we do something similar with Journald?
Keeping all
On 23/10/14 16:50, Lennart Poettering wrote:
> On Thu, 23.10.14 15:27, D.S. Ljungmark (spi...@aanstoot.se) wrote:
>
>> Hi,
>> we have a few services that are spamming a fair bit on DEBUG level of
>> log output. In syslog, we'd separate the DEBUG logs from the main
Hi
we have a service set to:
ConditionFileNotEmpty=
and
Restart=Always
This combination would (in my feebled mind) cause the service to restart
once the Condition was fulfilled, but that doesn't seem to be the case.
Is there a way I can get a service to restart even after it has been set
as i
Hi,
We're pondering to use the WatchdogSec=.. function, but wanted to know
what signal (if any) are sent to the application before termination.
Main reason is that we want to get a proper stacktrace of the daemon if
it is killed for some reason.
//D.S.
--
8362 CB14 98AD 11EF CEB6 FA81 FCC3 767
On 24/11/14 17:58, Peter Sztanojev wrote:
> On Mon, Nov 24, 2014 at 5:39 PM, D.S. Ljungmark wrote:
>> Hi,
>> We're pondering to use the WatchdogSec=.. function, but wanted to know
>> what signal (if any) are sent to the application before termination.
>>
>>
On 10/11/14 23:09, Lennart Poettering wrote:
> On Thu, 30.10.14 18:47, D.S. Ljungmark (spi...@aanstoot.se) wrote:
>
>> Hi
>> we have a service set to:
>> ConditionFileNotEmpty=
>>
>> and
>>
>> Restart=Always
>>
>>
>> This c
On 24/11/14 20:30, Umut Tezduyar Lindskog wrote:
> Hi
>
> On Monday, November 24, 2014, D.S. Ljungmark <mailto:spi...@aanstoot.se>> wrote:
>
> On 10/11/14 23:09, Lennart Poettering wrote:
> > On Thu, 30.10.14 18:47, D.S. Ljungmark (spi...@aanstoot.se
>
On 01/12/14 01:20, Lennart Poettering wrote:
> On Mon, 24.11.14 20:02, D.S. Ljungmark (spi...@aanstoot.se) wrote:
>
>> Basically, some files (config & certificates) may not exist on a system
>> until it's provisioned properly, something that may take a while (
On 24/10/14 00:47, Lennart Poettering wrote:
> On Thu, 23.10.14 17:19, D.S. Ljungmark (spi...@aanstoot.se) wrote:
>
>>
>>
>> On 23/10/14 16:50, Lennart Poettering wrote:
>>> On Thu, 23.10.14 15:27, D.S. Ljungmark (spi...@aanstoot.se) wrote:
>>>
>&
hi,
Our / partitions are on a squashfs media, which means that unit files
are read-only. There is a partition for read-write content
(Scratchable), and I'm wondering if it would be possible to add
unit-files there and have the boot order cope with this correctly?
How should this be set up -prop
27 matches
Mail list logo