On 16-12-14 04:56:19, Ed Greshko wrote:
On 12/14/16 14:01, Ed Greshko wrote:
> I wonder if there is a race condition within the systemd processes
at times.
I pretty much believe this to be the case since I've been doing some
extensive testing and
on a system that was consistently not
On 12/14/16 14:01, Ed Greshko wrote:
> I wonder if there is a race condition within the systemd processes at
> times.
I pretty much believe this to be the case since I've been doing some extensive
testing and
on a system that was consistently not showing the "sm-client.service: Failed to
On 12/14/16 13:28, Tony Nelson wrote:
> On 16-12-14 00:09:52, Ed Greshko wrote:
> ...
>> I also don't know what "Invalid argument" is suppose to mean/indicate.
>
> The first time systemd reads the pid file it is still empty. That seems
> sort of invalid.
>
Hummm The man pages for systemd
On 16-12-14 00:09:52, Ed Greshko wrote:
...
I also don't know what "Invalid argument" is suppose to mean/indicate.
The first time systemd reads the pid file it is still empty. That seems
sort of invalid.
--
TonyN.:'
On 12/14/16 13:14, Stephen Davies wrote:
> You've explained the -Ac but what does the -L do (apart from appearing in the
> log)?
Apparently, nothing.
From my readable man page
-L tag Set the identifier used in syslog messages to the supplied tag.
--
You're Welcome Zachary Quinto
__
On 14/12/16 15:23, Tony Nelson wrote:
On 16-12-13 22:07:10, Stephen Davies wrote:
I manually created an empty /run/sm-client.pid and set the ownership to
smmsp:smmsp and the ran systemctl.
It failed again as before but after the failure, /run/sm-client.pid did not
exist.
What is actually tryi
On 12/14/16 12:56, Tony Nelson wrote:
> On 16-12-13 23:13:46, Ed Greshko wrote:
> ...
>> Dec 14 12:02:47 f25cinn.greshko.com systemd[1]: Starting Sendmail Mail
>> Transport Client...
>> Dec 14 12:02:48 f25cinn.greshko.com systemd[1]: sm-client.service: Failed to
>> read PID from
>> file /run/s
On 16-12-13 23:13:46, Ed Greshko wrote:
...
Dec 14 12:02:47 f25cinn.greshko.com systemd[1]: Starting Sendmail
Mail Transport Client...
Dec 14 12:02:48 f25cinn.greshko.com systemd[1]: sm-client.service:
Failed to read PID from
file /run/sm-client.pid: Invalid argument
Dec 14 12:02:48 f25cinn.
On 16-12-13 22:07:10, Stephen Davies wrote:
I manually created an empty /run/sm-client.pid and set the ownership
to smmsp:smmsp and the ran systemctl.
It failed again as before but after the failure, /run/sm-client.pid
did not exist.
What is actually trying to write/read the PID file?
/
Just to deepen the "mystery".
Just the other day I had created a fresh F25 VM to play with the Cinnamon
desktop. It did
not have sendmail installed... So, I just installed and tried things out...
This was just after the install...
[root@f25cinn ~]# systemctl status sm-client
● sm-client.
On 12/14/16 11:07, Stephen Davies wrote:
>
> I manually created an empty /run/sm-client.pid and set the ownership to
> smmsp:smmsp and
> the ran systemctl.
>
> It failed again as before but after the failure, /run/sm-client.pid did not
> exist.
>
> What is actually trying to write/read the PID
On 14/12/16 13:14, Tony Nelson wrote:
On 16-12-13 19:27:21, Stephen Davies wrote:
On 14/12/16 02:03, Tony Nelson wrote:
On 16-12-13 02:49:53, Stephen Davies wrote:
I have no idea where the reference to
/var/spool/clientmqueue/sm-client.pid
comes from.
The pidfile should come from /etc/mail/
On 16-12-13 19:27:21, Stephen Davies wrote:
On 14/12/16 02:03, Tony Nelson wrote:
On 16-12-13 02:49:53, Stephen Davies wrote:
I have no idea where the reference to
/var/spool/clientmqueue/sm-client.pid
comes from.
The pidfile should come from /etc/mail/submit.mc via
/etc/mail/submit.cf
On 12/14/16 08:27, Stephen Davies wrote:
> The process is definitely running as smmsp so should have write access to the
> PID file.
The pid file /run/sm-client.pid doesn't get deleted when the processes are
stopped.
If you had a configuration where it was created but owned by root:root it w
On 14/12/16 02:03, Tony Nelson wrote:
On 16-12-13 02:49:53, Stephen Davies wrote:
I have no idea where the reference to
/var/spool/clientmqueue/sm-client.pid
comes from.
The pidfile should come from /etc/mail/submit.mc via /etc/mail/submit.cf
THANK YOU!!
That is indeed where /var/spool/clie
On 16-12-13 02:49:53, Stephen Davies wrote:
> I have no idea where the reference to
> /var/spool/clientmqueue/sm-client.pid
> comes from.
The pidfile should come from /etc/mail/submit.mc via /etc/mail/submit.cf
--
TonyN.:'
On 12/13/16 16:12, Ed Greshko wrote:
> Well, all I can tell you is that I used the default settings and this is what
> I get
Not knowing how you're making modifications to your system I suppose I would
grep clientmqueue /lib/systemd/system/*service
to see if a file with that info hasn't b
On 12/13/16 15:49, Stephen Davies wrote:
> On 13/12/16 16:30, Ed Greshko wrote:
>>
>>
>> On 12/13/16 13:48, Ed Greshko wrote:
>>> When you make changes to a file I believe you need to issue the "systemctl
>>> daemon-reload".
>>
>> OK Here is the warning I recall reading
>>
>> WARNING
>>
On 13/12/16 16:30, Ed Greshko wrote:
On 12/13/16 13:48, Ed Greshko wrote:
When you make changes to a file I believe you need to issue the "systemctl
daemon-reload".
OK Here is the warning I recall reading
WARNING
Always run the systemctl daemon-reload command after creating new un
On 12/13/16 13:48, Ed Greshko wrote:
> When you make changes to a file I believe you need to issue the "systemctl
> daemon-reload".
OK Here is the warning I recall reading
WARNING
Always run the systemctl daemon-reload command after creating new unit files or
modifying
existing unit
On 12/13/16 13:40, Stephen Davies wrote:
> I agree that the "same error" is weird - but it is happening.
> Here is the output from a start of the original service:
>
> [root@mustang system]# systemctl status sm-client
> ● sm-client.service - Sendmail Mail Transport Client
>Loaded: loaded (/us
On 13/12/16 16:04, Ed Greshko wrote:
On 12/13/16 13:19, Stephen Davies wrote:
Have you tried running with the default sm-client.service file instead of the
modified
version?
Yes. That is why I have a modified version.
The original gave the same error so I tried to make the PID file availab
On 13/12/16 15:49, Samuel Sieb wrote:
On 12/11/2016 07:40 PM, Stephen Davies wrote:
If I try to start sm-client with systemctl, I get:
Dec 12 13:32:04 mustang.sdc.com.au sm-msp-queue2[5951]: unable to write
pid to /var/spool/clientmqueue/sm-client.pid: Permission denied
This seems like a like
On 12/13/16 13:19, Stephen Davies wrote:
>> Have you tried running with the default sm-client.service file instead of
>> the modified
>> version?
>>
>>
> Yes. That is why I have a modified version.
> The original gave the same error so I tried to make the PID file available.
I find that odd th
On 12/11/2016 07:40 PM, Stephen Davies wrote:
If I try to start sm-client with systemctl, I get:
Dec 12 13:32:04 mustang.sdc.com.au sm-msp-queue2[5951]: unable to write
pid to /var/spool/clientmqueue/sm-client.pid: Permission denied
This seems like a likely issue.
I am 99.99% sure that all m
On 13/12/16 15:42, Ed Greshko wrote:
On 12/12/16 11:40, Stephen Davies wrote:
If I try to start sm-client with systemctl, I get:
Dec 12 13:32:04 mustang.sdc.com.au sm-msp-queue2[5951]: starting daemon
(8.15.1):
queueing@01:00:00
Dec 12 13:32:04 mustang.sdc.com.au sm-msp-queue2[5951]: unable
On 12/12/16 11:40, Stephen Davies wrote:
> If I try to start sm-client with systemctl, I get:
>
> Dec 12 13:32:04 mustang.sdc.com.au sm-msp-queue2[5951]: starting daemon
> (8.15.1):
> queueing@01:00:00
> Dec 12 13:32:04 mustang.sdc.com.au sm-msp-queue2[5951]: unable to write pid to
> /var/spool/
If I try to start sm-client with systemctl, I get:
Dec 12 13:32:04 mustang.sdc.com.au sm-msp-queue2[5951]: starting daemon
(8.15.1): queueing@01:00:00
Dec 12 13:32:04 mustang.sdc.com.au sm-msp-queue2[5951]: unable to write pid to
/var/spool/clientmqueue/sm-client.pid: Permission denied
Dec 12 1
28 matches
Mail list logo
