log message meaning

[François Patte]

Bonjour,

1--- I masked the firewalld service because I don't want to use it,. Il
the log messages, I get this information:

irewalld.service: Cannot add dependency job

How can I know what jobs depend on firewalld?

2--- What is the meaning of this message:

iscsi.service: Unit cannot be reloaded because it is inactive.

3-- And always this message:

var.mount: Directory /var to mount over is not empty

Why does cups creates directories in /var before /var is mounted?

Thank you.

-- 
François Patte
UFR de mathématiques et informatique
Laboratoire CNRS MAP5, UMR 8145
Université Paris Descartes
45, rue des Saints Pères
F-75270 Paris Cedex 06
Tél. [phone]
http://www.math-info.univ-paris5.fr/~patte

[stan]

On Fri, 5 May 2017 10:55:41 +0200
François Patte <francois.patte(a)mi.parisdescartes.fr&gt; wrote:

>  Bonjour,
>  
>  1--- I masked the firewalld service because I don't want to use it,.
>  Il the log messages, I get this information:
>  
>  irewalld.service: Cannot add dependency job
>  
>  How can I know what jobs depend on firewalld? 
On my system,
# dnf -C remove firewalld
Dependencies resolved.
=========
 Package 
=========
Removing:
 anaconda-core 
 anaconda-tui
 fail2ban
 fail2ban-firewalld
 firewall-config
 firewalld
 initial-setup

Of those, I think the only relevant one for an already installed system
would be fail2ban.

>  
>  2--- What is the meaning of this message:
>  
>  iscsi.service: Unit cannot be reloaded because it is inactive. 
I think it somewhat depends on context. (found by searching on
'iscsi.service: Unit cannot be reloaded because it is inactive')

http://www.fedoraforum.org/forum/showthread.php?t=313488

or it could just be warning / informational that systemd is trying to
reload this service because of internal operations and dependencies,
and it isn't possible because it isn't active because there are no scsi
devices.

>  
>  3-- And always this message:
>  
>  var.mount: Directory /var to mount over is not empty
>  
>  Why does cups creates directories in /var before /var is mounted? 
Not sure about this.  These seems relevant. (found by searching on
'Directory /var to mount over is not empty'

http://forums.fedoraforum.org/showthread.php?t=295214

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850436

[Tim]

Allegedly, on or about 05 May 2017, François Patte sent:
>  var.mount: Directory /var to mount over is not empty
>  
>  Why does cups creates directories in /var before /var is mounted?  
Sounds like yet another systemd snafu.  

Previously system start-up scripts were run sequentially.  And if
something required something else to be available first, then you
arranged the order of scripts accordingly.  

Now everything tries to start concurrently, and some things don't always
start up with the same speed each boot, so your sequencing can change
(what worked last week, might not today).  A similar remedy exists, now,
where scripts can wait for particular things to happen before they do
their bit (such as having cups wait for the network to be up and for var
to be mounted), but not all those conditions have been anticipated, so
various scripts work more by luck than good planning.

There is another approach:  If you don't need var to be a separate
mount, and most people don't, var can simply be a directory in root.

-- 
[tim@localhost ~]$ uname -rsvp
Linux 3.9.10-100.fc17.x86_64 #1 SMP Sun Jul 14 01:31:27 UTC 2013 x86_64

Boilerplate:  All mail to my mailbox is automatically deleted, there is
no point trying to privately email me, I only get to see the messages
posted to the mailing list.

Linux servers are always being dæmonised...

[Rick Stevens]

On 05/05/2017 01:55 AM, François Patte wrote:
>  Bonjour,
>  
>  1--- I masked the firewalld service because I don't want to use it,. Il
>  the log messages, I get this information:
>  
>  irewalld.service: Cannot add dependency job
>  
>  How can I know what jobs depend on firewalld? 
You can ask systemctl:

	# systemctl -l --before list-dependencies firewalld.service

>  2--- What is the meaning of this message:
>  
>  iscsi.service: Unit cannot be reloaded because it is inactive. 
You probably don't have any iSCSI devices so the iscsi.service went
inactive or you have it disabled. Not uncommon and I wouldn't worry
about it unless you plan to use iSCSI sometime in the future.

>  3-- And always this message:
>  
>  var.mount: Directory /var to mount over is not empty
>  
>  Why does cups creates directories in /var before /var is mounted? 
Looking at the cups.service file, it doesn't have a

	after=local-fs.target

specification, so it doesn't wait until local-fs.target has been
launched before running. I guess the assumption is that most systems
now use a single, monolithic filesystem with /var simply a directory of
the root filesystem. IMHO that's a stupid assumption to make, but
there's a lot of stuff I detest about systemd.

I suppose you could edit /usr/lib/systemd/system/cups.service and add
" local-fs.target" to the "[Unit]" section's "After="
line as shown
below:

	[Unit]
	Description=CUPS Scheduler
	Documentation=man:cupsd(8)
	After=network.target local-fs.target

	[Service]
	ExecStart=/usr/sbin/cupsd -l
	Type=notify

	[Install]
	Also=cups.socket cups.path
	WantedBy=printer.target

Then reboot and verify that cups waits for /var to be mounted before
starting. You might also submit a bugzilla for this as I'm sure you're
not the only one getting hit by this.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, AllDigital    ricks(a)alldigital.com -
- AIM/Skype: therps2        ICQ: 226437340           Yahoo: origrps2 -
-                                                                    -
-           grep me no patterns and I'll tell you no lines           -
----------------------------------------------------------------------

[Samuel Sieb]

On 05/05/2017 10:44 AM, Rick Stevens wrote:
>  I suppose you could edit /usr/lib/systemd/system/cups.service and
> add
>  " local-fs.target" to the "[Unit]" section's "After="
> line as shown
>  below:
>   
The better way is to copy that file to /etc/systemd/system/cups.service 
and edit it there.  That way it won't get overwritten every time you 
upgrade cups.  Files in /etc override the ones in /usr/lib.

[Tim]

Allegedly, on or about 05 May 2017, Rick Stevens sent:
>  Looking at the cups.service file, it doesn't have a
>  
>          after=local-fs.target
>  
>  specification, so it doesn't wait until local-fs.target has been
>  launched before running. I guess the assumption is that most systems
>  now use a single, monolithic filesystem with /var simply a directory
>  of the root filesystem. IMHO that's a stupid assumption to make, but
>  there's a lot of stuff I detest about systemd.  
I agree.  And while there has been a push to having one huge root
partition, of late.  I dare say that there might be a push back for
separating some things, with a bunch of people having mixed hard disc
and SSD systems, putting the things you want to be nippy on SSD and the
long term storage that you don't trust the SSD for, on the HDD.

-- 
[tim@localhost ~]$ uname -rsvp
Linux 3.9.10-100.fc17.x86_64 #1 SMP Sun Jul 14 01:31:27 UTC 2013 x86_64

Boilerplate:  All mail to my mailbox is automatically deleted, there is
no point trying to privately email me, I only get to see the messages
posted to the mailing list.

Just because nobody complains, it doesn't mean that all parachutes are
perfect.

[Gordon Messmer]

On 05/05/2017 10:44 AM, Rick Stevens wrote:
>  I suppose you could edit /usr/lib/systemd/system/cups.service 
Use "systemctl edit cups.service"