On 6/2/2016 11:28 AM, Reindl Harald wrote:
Am 02.06.2016 um 19:24 schrieb JB:
On 6/2/2016 11:01 AM, Reindl Harald wrote:
Am 02.06.2016 um 18:50 schrieb Greg KH:
On Thu, Jun 02, 2016 at 06:29:50PM +0200, Reindl Harald wrote:
Am 02.06.2016 um 18:20 schrieb Greg KH:
Ok, but please ask
On 6/2/2016 10:20 AM, Greg KH wrote:
On Thu, Jun 02, 2016 at 10:14:22AM -0600, JB wrote:
Hi Greg,
Thank you very much for responding!
On 6/2/2016 9:46 AM, Greg KH wrote:
On Thu, Jun 02, 2016 at 06:24:39AM -0600, JB wrote:
I'm running kernel 3.18.22. I'm seeing some odd beh
Hi Greg,
Thank you very much for responding!
On 6/2/2016 9:46 AM, Greg KH wrote:
On Thu, Jun 02, 2016 at 06:24:39AM -0600, JB wrote:
I'm running kernel 3.18.22. I'm seeing some odd behavior from systemd. The
motherboard is an intel board with dual onboard NIC. I installed FC21
init
I'm running kernel 3.18.22. I'm seeing some odd behavior from systemd.
The motherboard is an intel board with dual onboard NIC. I installed
FC21 initially with secondary ethernet interface disabled in the BIOS.
Then after install, I enabled it. However, while the first NIC name
comes up as expe
Hello,
I've run into another "side-effect" of systemd's supervisory power
over processes. The application is a simple ruby webrick daemon. It
get's started just fine. It provides web service configuration to an
appliance. One of the service calls gives clients the ability to power
down
Lennart Poettering wrote:
On Tue, 22.01.13 02:33, JB (gene...@itpsg.com) wrote:
Subsequent starts and stops of the application of course do not
change those process ID and kernel threads because, I can only
assume, they are reused. A kill -9 as root will not even kill them.
The problem I
#x27;m trying to get this figured out so system shutdowns and
service restarts will not take forever compared to startup. Any help
would be immensely appreciated!
Thanks,
JB
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http:
Zbigniew Jędrzejewski-Szmek wrote:
It gets better. I took a very stripped simple daemon to try to
understand the interaction between systemd and the process. Here it
is:
Hi,
your process is forking as it should (as least on my machine).
^not (arghhh!)
Zbigniew Jędrzejewski-Szmek wrote:
On Wed, Jan 02, 2013 at 02:28:19AM -0700, JB wrote:
Andrey Borzenkov wrote:
В Tue, 01 Jan 2013 23:37:56 -0700
JB пишет:
Andrey Borzenkov wrote:
В Tue, 01 Jan 2013 18:52:38 -0700
JB пишет:
Thanks! I'll try and i
Andrey Borzenkov wrote:
В Wed, 02 Jan 2013 04:02:27 -0700
JB пишет:
Andrey Borzenkov wrote:
В Wed, 02 Jan 2013 02:28:19 -0700
JB пишет:
Here's the service file:
***
[Unit]
Description=Webrick Test Service
After=network.t
Andrey Borzenkov wrote:
В Wed, 02 Jan 2013 02:28:19 -0700
JB пишет:
Here's the service file:
***
[Unit]
Description=Webrick Test Service
After=network.target
[Service]
Type=forking
ExecStart=/usr/bin/ruby /home/rtuser/test.rb
[Install]
Wan
Andrey Borzenkov wrote:
В Tue, 01 Jan 2013 23:37:56 -0700
JB пишет:
Andrey Borzenkov wrote:
В Tue, 01 Jan 2013 18:52:38 -0700
JB пишет:
Thanks! I'll try and it may work in my case. What's interesting is
that in your case it sounded like rsyslog was hanging aroun
Andrey Borzenkov wrote:
В Tue, 01 Jan 2013 23:37:56 -0700
JB пишет:
Andrey Borzenkov wrote:
В Tue, 01 Jan 2013 18:52:38 -0700
JB пишет:
Thanks! I'll try and it may work in my case. What's interesting is
that in your case it sounded like rsyslog was hanging ar
Andrey Borzenkov wrote:
В Tue, 01 Jan 2013 18:52:38 -0700
JB пишет:
Thanks! I'll try and it may work in my case. What's interesting is
that in your case it sounded like rsyslog was hanging around while it
was having problems dealing with the condition of having the network
u
ave quite a bit of those. I call these types of
solutions "technical debt" because sooner or later you will wind up
having to paying for it :)
JB
Reindl Harald wrote:
Am 02.01.2013 01:27, schrieb JB:
Hello all,
I do have one more question about systemd. Sometimes, it takes
y ideas on how I can diagnose this or solve it.
JB
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Thank you!
Lennart Poettering wrote:
On Sun, 30.12.12 18:50, JB (gene...@itpsg.com) wrote:
Bottom line is I need to give a process started by systemd and any
process started by that process some privileges to chanage scheduler
and
I'm sorry for not thanking you for the rapid reply! I am grateful for
your attention on this! That is probably the fastest response I've ever
had on any mailing list. Very impressive!
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.or
NOT solving the problem. I've practically memorized all the
systemd man pages. While I admit, I could have missed something over
the last 3 weeks of diligent study on systemd I think I've RTFM
waaay too much for anyone here to say "RTFM" with any credibility
Bottom line is I need to give a process started by systemd and any
process started by that process some privileges to chanage scheduler and
other things when it starts. How do I tell systemd to grant these
privileges to one of it's services?
Here's all the detail:
I'm having a really frust
After browsing through git I think I may have a viable solution to the
main issue of not being able to change that hostname before it is set at
boot time.
Move the logic from hostname-setup.c into hostnamed a hostnamed
Make a hostnamed --setfromfile option and use in in a
set-hostname.service
I'm a happy Arch Linux user of systemd. I want to share a few of my
thoughts about systemd's interaction with the system hostname.
Here's my understanding of how systemd currently sets the hostname
* hostnamed is included in the systemd package
* During early boot systemd makes a call t
22 matches
Mail list logo